CN113296910A - File system calling method and device, terminal equipment and readable storage medium - Google Patents

File system calling method and device, terminal equipment and readable storage medium Download PDF

Info

Publication number
CN113296910A
CN113296910A CN202110534212.8A CN202110534212A CN113296910A CN 113296910 A CN113296910 A CN 113296910A CN 202110534212 A CN202110534212 A CN 202110534212A CN 113296910 A CN113296910 A CN 113296910A
Authority
CN
China
Prior art keywords
file system
interface
task
calling
running task
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202110534212.8A
Other languages
Chinese (zh)
Other versions
CN113296910B (en
Inventor
曾祥安
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ubtech Robotics Corp
Original Assignee
Ubtech Robotics Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ubtech Robotics Corp filed Critical Ubtech Robotics Corp
Priority to CN202110534212.8A priority Critical patent/CN113296910B/en
Publication of CN113296910A publication Critical patent/CN113296910A/en
Application granted granted Critical
Publication of CN113296910B publication Critical patent/CN113296910B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/11File system administration, e.g. details of archiving or snapshots
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Stored Programmes (AREA)

Abstract

The application is applicable to the technical field of file system application, and provides a file system calling method, a device, a terminal device and a readable storage medium, wherein the method comprises the following steps: the method comprises the steps that terminal equipment calls an interface of a preset file system, wherein the interface is obtained by packaging the preset file system aiming at an operation task; identifying a handle of the running task through the virtual file system to obtain the category of the running task; and calling an operation function corresponding to the running task in a preset file system according to the category of the running task. By the method and the device, the problem that the calling of the file system is inconvenient when the operating system runs tasks of different languages can be solved, and the effective access of multi-type running tasks is realized while the structural integrity of the original system is ensured.

Description

File system calling method and device, terminal equipment and readable storage medium
Technical Field
The application belongs to the technical field of file system application, and particularly relates to a file system calling method and device, a terminal device and a readable storage medium.
Background
File System (FS) is a method and data structure used by an operating System to specify files on a storage device or partition, i.e., a software mechanism that organizes, manages, and stores File information on a storage device; the system is mainly responsible for organizing and distributing the space of the file storage device, storing the files, protecting and retrieving the stored files and the like.
The Micro Python is a Python interpreter and runtime system running on top of the microcontroller hardware. Under the Micro Python system framework, the adopted file system can only be called step by step under Python language codes, and the calling of the file system is difficult to realize aiming at other non-Python language codes in product application, so that when an operating system runs tasks of different language codes, a lot of inconvenience exists in the calling of the file system, and even the integrity of the original Micro Python system framework can be damaged.
Disclosure of Invention
The embodiment of the application provides a file system calling method, a file system calling device, terminal equipment and a readable storage medium, and can solve the problem that when an operating system runs tasks of different languages, calling of a file system is inconvenient.
In a first aspect, an embodiment of the present application provides a method for calling a file system, where the method includes:
calling an interface of a preset file system, wherein the interface is obtained by packaging the preset file system aiming at an operation task; identifying a handle of the running task through a virtual file system to obtain the category of the running task; and calling an operation function corresponding to the running task in the preset file system according to the category of the running task.
In one possible implementation manner of the first aspect, the interface includes an original interface and a locked interface; before the calling the interface of the preset file system, the method further comprises:
packaging the preset file system to obtain an original interface corresponding to the running task of the preset language type; and locking and packaging the original interface of the preset file system to obtain a locked interface with a mutual exclusion lock.
In a possible implementation manner of the first aspect, the invoking an interface of a preset file system includes:
calling the locked interface of the preset file system; and if the locked interface does not have the corresponding running task, continuing to call the original interface of the preset file system.
In a possible implementation manner of the first aspect, the identifying, by the virtual file system, a handle of the running task to obtain a category of the running task includes:
obtaining a handle of the running task by calling an operation function of the virtual file system; and determining the type of the running task according to the target object in the handle.
In a possible implementation manner of the first aspect, the calling, according to the category of the running task, an operation function corresponding to the running task in the preset file system includes:
if the running task is a first language code task, calling an operation driving function corresponding to the first language code task in the preset file system; if the running task is a second language code task, calling an operation entry function corresponding to the second language code task in the preset file system, and calling the operation driving function according to the operation entry function.
In a possible implementation manner of the first aspect, the method further includes:
and after the running task is executed, releasing the locked interface to enable the locked interface to be recovered to an available state.
In a second aspect, an embodiment of the present application provides a file system calling apparatus, where the apparatus includes:
the first calling unit is used for calling an interface of a preset file system, and the interface is obtained by packaging the preset file system aiming at an operation task;
the identification unit is used for identifying the handle of the running task through a virtual file system to obtain the category of the running task;
and the second calling unit is used for calling an operation function corresponding to the running task in the preset file system according to the category of the running task.
In a possible implementation manner of the first aspect, the apparatus further includes:
and the packaging unit is used for locking and packaging the original interface of the preset file system to obtain a locked interface with a mutual exclusion lock.
In a third aspect, an embodiment of the present application provides a terminal device, where the terminal device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the method according to any one of the first aspect when executing the computer program.
In a fourth aspect, the present application provides a computer-readable storage medium, which stores a computer program, and when the computer program is executed by a processor, the computer program implements the method of any one of the first aspect.
In a fifth aspect, the present application provides a computer program product, which when run on a terminal device, causes the terminal device to execute the method of any one of the above first aspects.
It is to be understood that the beneficial effects of the second to fifth aspects can be seen from the description of the first aspect, and are not repeated herein.
Compared with the prior art, the embodiment of the application has the advantages that: according to the method and the device, the terminal equipment calls an interface of the preset file system, and the interface is obtained by packaging the preset file system aiming at the running task; identifying a handle of the running task through the virtual file system to obtain the category of the running task; calling an operation function corresponding to the running task in a preset file system according to the category of the running task; according to the method and the device, the type of the running task is determined by identifying the running task, so that the corresponding operation function can be called according to the type of the running task, the problem that the file system is inconvenient to call when an operating system runs tasks of different languages is solved, and the integrity of an original running system architecture is prevented from being damaged; the integrity of the original operation system architecture is ensured, and meanwhile, the effective access of multi-type operation tasks is realized; has strong usability and practicability.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.
FIG. 1 is a schematic diagram of a system architecture provided by an embodiment of the present application;
fig. 2 is a schematic flowchart of a file system calling method according to an embodiment of the present application;
FIG. 3 is a schematic flow chart of an overall method provided by another embodiment of the present application;
FIG. 4 is a schematic structural diagram of a file system calling apparatus according to an embodiment of the present application;
fig. 5 is a schematic structural diagram of a terminal device according to an embodiment of the present application.
Detailed Description
In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.
It will be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
It should also be understood that the term "and/or" as used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.
As used in this specification and the appended claims, the term "if" may be interpreted contextually as "when", "upon" or "in response to" determining "or" in response to detecting ". Similarly, the phrase "if it is determined" or "if a [ described condition or event ] is detected" may be interpreted contextually to mean "upon determining" or "in response to determining" or "upon detecting [ described condition or event ]" or "in response to detecting [ described condition or event ]".
Furthermore, in the description of the present application and the appended claims, the terms "first," "second," "third," and the like are used for distinguishing between descriptions and not necessarily for describing or implying relative importance.
Reference throughout this specification to "one embodiment" or "some embodiments," or the like, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather "one or more but not all embodiments" unless specifically stated otherwise. The terms "comprising," "including," "having," and variations thereof mean "including, but not limited to," unless expressly specified otherwise.
The Micro Python is a complete software implementation of Python3 programming language, written in C language, and may run on a Python interpreter and runtime system on the microcontroller hardware. The conventional File system of the micro python uses a File Allocation Table (FAT) File system, and the FAT File system is a centralized index File system, does not have a function of balancing loss, and is not suitable for being directly operated on a nonvolatile storage medium flash, while the storage medium often used by a microcontroller is the flash. Therefore, a file system suitable for use in the embedded microcontroller needs to be selected and migrated to the MicroPython, such as littleFS file system.
With the gradual increase of the application complexity, the tasks corresponding to the application are more and more. However, after being transplanted to a file system under a Micro Python system architecture, the file system can be called step by step only under Python language codes; the operation tasks (such as user function tasks) aiming at other non-Micro Python language codes are difficult to call the file system. Due to the self-integrity of the Micro Python system framework, no interface is provided for allowing the user function task (C language code task) to call the file system. Because the user function task has the possibility of accessing the file system on other language code levels, if the original calling process is adopted, the self-integrity of the MicroPython system architecture can be damaged; therefore, when the operating system runs tasks of different language codes, a lot of inconvenience exists in calling the file system.
In addition, the file system itself transplanted to the Micro Python system architecture cannot guarantee the security of the threads, and how to avoid the phenomenon that the file is damaged due to the fact that different task threads (for example, the task thread of the Micro Python framework and the thread of the user function task) operate the same file at the same time is also a technical problem to be solved by the embodiment of the present application.
Referring to fig. 1, a system architecture diagram according to an embodiment of the present application is provided. In an embedded microcontroller, a Micro Python framework-based runtime system adopts a preset file system littleFS with balanced loss. When the preset file system littleFS is transplanted to the Micro Python runtime system, an interface API (i.e. an original interface) written based on C language codes is encapsulated in the preset file system, so that a user function task can access the preset file system on the C language code level. As shown in fig. 1, in an embedded microcontroller, an application layer is a framework layer for running tasks; the preset file system provided by the embodiment of the application can support the Micro Python task or the C language user function task, namely, the Micro Python task or the C language user function task can call an interface API written by the C language code of the preset file system.
The littleFS file system is mainly applied to the microcontroller and the flash, is an embedded file system, has the characteristics of power failure recovery, erasing balance, storage space saving and the like, and is very suitable for being used in the embedded microcontroller. And transplanting the littleFS to a Micro Python runtime system to realize operations such as reading, writing, erasing and the like on the storage device Flash. In addition, the Runtime system is a kind of run mode that is subject to compiling and interpretation, the compiler first compiles the source code into an intermediate code, and the Runtime (Runtime) acts as an Interpreter (Interpreter) to interpret it during execution; i.e., the environment in which the semi-compiled run code is run on the target machine.
The storage device Flash stores a drive function for performing operations such as reading, writing, erasing, synchronizing and the like on a preset file system littleFS; meanwhile, a Flash operation entry function of the Micro Python kernel is stored, so that when the operation task is the Micro Python task, the step-by-step downward calling of the preset file system littleFS is realized under a Micro Python framework. When the running task accesses the littleFS file system, the type of the running task is identified, different operation functions are called based on the type of the running task, and therefore the possibility that the access process of other user function tasks damages the kernel architecture of the Micro Python can be avoided.
In addition, under the operating system of the embedded microcontroller, the bottom layer simulates a thread through a process, the thread is an execution stream inside the process, and most of resources of the file system are shared by the multi-thread process, so that a plurality of threads running tasks can possibly access the same resource of the file system at the same time, and another thread can possibly access the same resource when one thread is accessing the same. In order to ensure the security of the thread accessing the same littleFS file system resource, an access interface API (original interface) of the littleFS is further encapsulated, so that a locked interface with a mutual exclusion lock is obtained. When a running task initiates calling of a locked interface, if other threads lock the interface or initiate calling while other threads exist, the exclusive lock enters a waiting state, and after the task of the last thread is executed and the locked interface is released, the exclusive lock calls the locked interface in time and locks the locked interface, so that the possibility that different threads access the same file system resource to damage the file system resource can be avoided.
By the embodiment of the application, on the premise of not destroying the self-integrity of the Micro Python framework, an interface (C interface) for accessing the littleFS file system can be provided for a user function task at a C language code level when the littleFS file system is transplanted; when the user function task uses the C interface to perform operations such as file reading or storage, the self-integrity of the Micro Python framework is ensured; meanwhile, the security of threads for simultaneously accessing the same file system resource by the Micro Python task and the user function task is ensured through a mutual exclusion lock packaged by an original interface of the littleFS file system.
The following describes the flow steps of the file system calling method provided by the present application by using a specific embodiment.
Referring to fig. 2, a flowchart of a file system calling method provided in an embodiment of the present application is schematically illustrated. The method may comprise the steps of:
step S201, the host device calls an interface of a preset file system, where the interface is obtained by encapsulating the preset file system for the running task.
In some embodiments, the default file system is a file system of a Micro Python runtime system architecture, which is migrated into the embedded microcontroller, and may be a littleFS file system, for example. The running tasks may include tasks in different language codes, which may correspond to different threads. And encapsulating the file system interface into an interface which can be called by each language code task according to the task types of different language codes. For example, under the architecture of the Micro Python runtime system, the interface of the migrated littleFS file system is encapsulated as an interface (C interface) of C language code, and different types of runtime tasks can call the C interface of the littleFS file system.
In addition, the running task may include a Micro Python task or a user function task; the Micro Python task is a task type based on Python language codes, and the user function task is a task type based on C language codes. By setting the interface of the littleFS file system as the C interface of the C language code layer, the access of the Micro Python task and the access of the user function task can be realized.
Illustratively, the type of the file system interface can be further extended according to the type of the running task, and as the complexity of the application function increases, the access of different types of tasks to the file system resource can be supported.
In some embodiments, the interfaces may include an original interface and a locked interface; before the terminal device calls the interface of the preset file system, the file system calling method further comprises the following steps:
the method comprises the steps that terminal equipment encapsulates a preset file system to obtain an original interface corresponding to a running task of a preset language type; and the terminal equipment locks and encapsulates the original interface of the preset file system to obtain a locked interface with a mutual exclusion lock.
In some embodiments, the preset language type may be a C language type, and the original interface may be a C interface of a C language layer obtained by encapsulating the preset file system. In order to avoid the phenomenon that the file is damaged due to the fact that running tasks of different outgoing threads access the same resources of a file system, the terminal equipment carries out locking encapsulation on the original C interface again to obtain a locked interface with a mutual exclusion lock.
For example, the code form of the locked interface with the mutual exclusion obtained by locking and encapsulating the original interface can be represented as follows:
Figure BDA0003068990120000081
Figure BDA0003068990120000091
the type represents the type of the interface, for example, the type of the interface is "open", "close", etc., the type in lfs _ mutex _ xxx represents the type parameter of the interface, for example, the type parameter corresponding to the interface of the "close" type may include parameters such as a pointer type, a file pointer, or a path, etc.
In addition, the naming of the functions, the interface symbols and the like can be set in a self-defined mode, and the original interface can be packaged into the locked interface of the structure.
It should be noted that, through further locking and packaging of the original C interface, the locked interface with the mutual exclusion lock is obtained, and the original interface directly called in the Micro Python task code is changed into the locked interface directly called; the code of the user function task also directly calls the locked interface.
Referring to fig. 3, a flow diagram of an overall method according to another embodiment of the present application is provided. The steps of the embodiment of fig. 2 are further refined.
In some embodiments, the terminal device calls an interface of a preset file system, including:
step S301, the terminal device calls a locked interface of a preset file system;
step S302, if the lock interface has no corresponding running task, the terminal device continues to call the original interface of the preset file system.
In some embodiments, original interfaces originally and directly called by the Micro Python task codes are changed into locked interfaces directly; the code of the user function task also directly calls the locked interface. If the locked interface is currently in the release state and no corresponding running task locks the locked interface, the current running task can access the locked interface and can continue to access the original interface, and the corresponding subsequent flow is executed by calling the original interface.
It should be noted that, if a lock interface is currently in a lock state, it indicates that an existing running task is accessing the file system and the lock interface is locked, so that when other running tasks call the lock interface, the file system cannot be directly accessed, it is necessary to wait for the program to execute the previous running task and release the lock interface, so that the lock interface is restored to an accessible state, and other running tasks can access and call, and when other running tasks access, the lock interface is also locked. The original interface and the locked interface after locking packaging can be interfaces at C language level.
In addition, different running tasks correspond to different threads, and original interfaces (C interfaces) are further locked and packaged into locked interfaces with mutual exclusion locks, so that the defect that the running tasks of different threads access the same file system resource simultaneously to cause file damage can be avoided, and the safety of accessing the file system by the multi-thread running tasks is ensured.
Step S202, the terminal equipment identifies the handle of the running task through the virtual file system to obtain the category of the running task.
In some embodiments, the architecture of the Micro Python runtime system has a virtual file system, and a handle of a current running task can be acquired through a function of the virtual file system, so that the type of the running task is determined according to the content of the handle.
The virtual file system may be denoted as vfs _ lfsx.c, and the functions of the virtual file system in the Micro Python framework may include operation driving functions of reading, writing, erasing, and synchronizing. The handle can be a full-length type of data, and the data is a unique identifier of an access object and corresponds to the access object one by one. The access object may be a file, a block memory, or a resource. The handle can be used as a pointer of a memory address, and the object accessed by the running task and the address of the memory where the object is located can be determined by acquiring the content of the handle.
It should be noted that the terminal device calls a self-contained function through the virtual file system to obtain a handle of the running task, so as to determine which type of task is running according to the handle, return the handle of the running task, and obtain the type of the running task.
In some embodiments, as shown in fig. 3, the identifying, by the terminal device, a handle of the running task through the virtual file system to obtain the category of the running task includes:
step S303, the terminal equipment obtains a handle of an operation task by calling an operation function of the virtual file system;
and step S304, the terminal equipment determines the type of the running task according to the target object in the handle.
In some embodiments, the processor used by the terminal device may be an embedded microcontroller, and the memory uses Flash. In a terminal device, a Micro Python-based operating environment contains a virtual file system (which can be expressed as vfs _ lfsx.c), the virtual file system vfs is realized based on a oofatfs database, and the oofatfs database is a file system fatfs from an open source, that is, the entire virtual file system vfs is extended based on the file system fatfs.
The virtual file system has the operating functions of reading, writing, erasing, synchronizing and the like. After the operation task accesses the original interface, the virtual file system calls the self-contained function to obtain a handle of the operation task, the type of the operation task is judged according to the target object accessed corresponding to the handle, the handle of the operation task is returned, and the category result of the operation task is obtained. The target object may be a file or a resource in the Flash memory.
For example, the class result of the running task may be a Micro Python task or a user function task (C language code level).
Step 203, the terminal device calls an operation function corresponding to the running task in the preset file system according to the type of the running task.
In some embodiments, in order to prevent access of other user function tasks from damaging the self-completeness of the Micro Python operating environment in the terminal device, branches of an access flow are set for different types of operating tasks. According to the type of the running task, different access objects are called, for example, if the running task is a user function task, an operation driving function in a Flash memory can be directly called without passing through a Flash operation entry function of a Micro Python kernel or modifying codes of the Micro Python kernel, so that the running tasks of other types except the Micro Python task can successfully access resources of the file system under the condition of ensuring the self integrity of the Micro Python architecture.
For example, in a Micro Python operating environment, if the operating task is a Micro Python task, a Flash operation function, such as a Flash operation entry function, to a Micro Python kernel may be called down step by step under a Python code.
In some embodiments, the calling, by the terminal device, an operation function corresponding to the running task in the preset file system according to the category of the running task includes:
step S305, if the running task is a first language code task, the terminal device calls an operation driving function corresponding to the first language code task in a preset file system;
step S306, if the running task is the second language code task, the terminal device calls an operation entry function corresponding to the second language code task in the preset file system, and the terminal device calls an operation driving function according to the operation entry function.
In some embodiments, the first language code task may be a user function task at a C language level, and the second language code task may be a running task of Python language code. Different types of tasks are set to be different branches, resources of a file system are accessed according to different process nodes, the problem that operating tasks of non-Python language codes damage the architecture of the Micro Python kernel is avoided, the problem that the Micro Python kernel codes are modified is also avoided, and meanwhile, the probability that operating errors or shutdown faults and the like easily occur when other operating tasks participate in the architecture of the Micro Python kernel is also reduced.
Illustratively, if the type of the running task is a user function task based on C language codes, a Flash operation driving function of a file system can be directly called; if the type of the running task is the Micro Python task based on the Python language code, a Flash operation entry function of a Micro Python kernel can be called, and finally, a Flash operation drive function can be further called. Therefore, the call chain passing through the inlet of the Micro Python kernel and the call chain not passing through the inlet of the Micro Python kernel are divided, and the integrity of the Micro Python framework is ensured; and simultaneously, the user function task obtains an interface for accessing the file system on the C language level.
In some embodiments, the file system calling method further comprises:
step S307, after the terminal device executes the running task, releasing the locked interface, and restoring the locked interface to the available state.
In some embodiments, when the current running task is executed, after the current running task calls the locked interface, the locked interface is locked, the locked interface is in a locked state, and the running tasks of other threads need to wait for the unlocked locked interface to access. After the current running task is executed, releasing the locked interface to enable the locked interface to be in an accessible state; and then the program returns to continue to execute the next running task according to the same flow.
According to the method and the device, the terminal equipment identifies the running task and determines the type of the running task, so that the corresponding operation function can be called according to the type of the running task, the problem that the file system is inconvenient to call when an operating system runs tasks of different languages is solved, and the integrity of an original running system architecture is prevented from being damaged; the method and the system realize effective access of multi-type operation tasks while ensuring the structural integrity of the original operation system.
On the premise of not destroying the self-integrity of the Micro Python framework, the embodiment of the application can provide an interface (C interface) for accessing the littleFS file system for the user function task at the C language code level when the littleFS file system is transplanted; when the user function task uses the C interface to perform operations such as file reading or storage, the self-integrity of the Micro Python framework is ensured; meanwhile, the security that the Micro Python task and the user function task access the same file system resource at the same time is ensured through a mutual exclusion lock packaged by an interface of the littleFS file system.
It should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.
Corresponding to the file system calling method in the foregoing embodiment, an embodiment of the present application further provides a file system calling apparatus, as shown in fig. 4, the apparatus includes:
the first calling unit 41 is configured to call an interface of a preset file system, where the interface is obtained by encapsulating the preset file system for an operation task;
the identification unit 42 is used for identifying the handle of the running task through the virtual file system to obtain the category of the running task;
and a second calling unit 43, configured to call, according to the category of the executed task, an operation function corresponding to the executed task in the preset file system.
In some embodiments, the file system calling device further comprises:
the packaging unit is used for packaging the preset file system to obtain an original interface corresponding to the running task of the preset language type; and locking and packaging the original interface of the preset file system to obtain a locked interface with a mutual exclusion lock.
By the embodiment of the application, on the premise of not destroying the self-integrity of the Micro Python framework, an interface (C interface) for accessing the littleFS file system can be provided for a user function task at a C language code level when the littleFS file system is transplanted; when the user function task uses the C interface to perform operations such as file reading or storage, the self-integrity of the Micro Python framework is ensured; meanwhile, the security that the Micro Python task and the user function task access the same file system resource at the same time is ensured through a mutual exclusion lock packaged by an interface of the littleFS file system.
It should be noted that, for the information interaction, execution process, and other contents between the above-mentioned devices/units, the specific functions and technical effects thereof are based on the same concept as those of the embodiment of the method of the present application, and specific reference may be made to the part of the embodiment of the method, which is not described herein again.
It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-mentioned functions. Each functional unit and module in the embodiments may be integrated in one processing unit, or each unit may exist alone physically, or two or more units are integrated in one unit, and the integrated unit may be implemented in a form of hardware, or in a form of software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working processes of the units and modules in the system may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
The embodiments of the present application further provide a computer-readable storage medium, where a computer program is stored, and when the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.
The embodiments of the present application provide a computer program product, which when running on a terminal device, enables the terminal device to implement the steps in the above method embodiments when executed.
Fig. 5 is a schematic structural diagram of a terminal device 5 according to an embodiment of the present application. As shown in fig. 5, the terminal device 5 of this embodiment includes: at least one processor 50 (only one shown in fig. 5), a memory 51, and a computer program 52 stored in the memory 51 and operable on the at least one processor 50, wherein the processor 50 executes the computer program 52 to implement the steps in the calling method embodiment of any of the various file systems described above.
The terminal device 5 may be a desktop computer, a notebook, a palm computer, a cloud server, or other computing devices. The terminal device 5 may include, but is not limited to, a processor 50 and a memory 51. Those skilled in the art will appreciate that fig. 5 is only an example of the terminal device 5, and does not constitute a limitation to the terminal device 5, and may include more or less components than those shown, or combine some components, or different components, such as an input-output device, a network access device, and the like.
The Processor 50 may be a Central Processing Unit (CPU), and the Processor 50 may be other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic device, discrete hardware component, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The memory 51 may in some embodiments be an internal storage unit of the terminal device 5, such as a hard disk or a memory of the terminal device 5. The memory 51 may also be an external storage device of the terminal device 5 in other embodiments, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like, which are provided on the terminal device 5. Further, the memory 51 may also include both an internal storage unit and an external storage device of the terminal device 5. The memory 51 is used for storing an operating system, an application program, a BootLoader (BootLoader), data, and other programs, such as program codes of the computer program. The memory 51 may also be used to temporarily store data that has been output or is to be output.
The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium and can implement the steps of the embodiments of the methods described above when the computer program is executed by a processor. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer readable medium may include at least: any entity or device capable of carrying computer program code to a photographing apparatus/terminal apparatus, a recording medium, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), an electrical carrier signal, a telecommunications signal, and a software distribution medium. Such as a usb-disk, a removable hard disk, a magnetic or optical disk, etc. In certain jurisdictions, computer-readable media may not be an electrical carrier signal or a telecommunications signal in accordance with legislative and patent practice.
In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus/device and method may be implemented in other ways. For example, the above-described apparatus/device embodiments are merely illustrative, and for example, the division of the modules or units is only one logical division, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present application and are intended to be included within the scope of the present application.

Claims (10)

1. A method for calling a file system, the method comprising:
calling an interface of a preset file system, wherein the interface is obtained by packaging the preset file system aiming at an operation task;
identifying a handle of the running task through a virtual file system to obtain the category of the running task;
and calling an operation function corresponding to the running task in the preset file system according to the category of the running task.
2. The method of claim 1, wherein the interface comprises an original interface and a locked interface; before the calling the interface of the preset file system, the method further comprises:
packaging the preset file system to obtain an original interface corresponding to the running task of the preset language type;
and locking and packaging the original interface of the preset file system to obtain a locked interface with a mutual exclusion lock.
3. The method of claim 2, wherein said invoking an interface of a default file system comprises:
calling the locked interface of the preset file system;
and if the locked interface does not have the corresponding running task, continuing to call the original interface of the preset file system.
4. The method of claim 1, wherein identifying the handle to the running task via the virtual file system, resulting in the category of the running task, comprises:
obtaining a handle of the running task by calling an operation function of the virtual file system;
and determining the type of the running task according to the target object in the handle.
5. The method according to any one of claims 1 to 4, wherein the calling the operation function corresponding to the running task in the preset file system according to the category of the running task comprises:
if the running task is a first language code task, calling an operation driving function corresponding to the first language code task in the preset file system;
if the running task is a second language code task, calling an operation entry function corresponding to the second language code task in the preset file system, and calling the operation driving function according to the operation entry function.
6. The method of claim 2 or 3, wherein the method further comprises:
and after the running task is executed, releasing the locked interface to enable the locked interface to be recovered to an available state.
7. A calling apparatus of a file system, the apparatus comprising:
the first calling unit is used for calling an interface of a preset file system, and the interface is obtained by packaging the preset file system aiming at an operation task;
the identification unit is used for identifying the handle of the running task through a virtual file system to obtain the category of the running task;
and the second calling unit is used for calling an operation function corresponding to the running task in the preset file system according to the category of the running task.
8. The apparatus of claim 7, wherein the apparatus further comprises:
and the packaging unit is used for locking and packaging the original interface of the preset file system to obtain a locked interface with a mutual exclusion lock.
9. A terminal device, characterized in that the terminal device comprises a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the method according to any of claims 1 to 6 when executing the computer program.
10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1 to 6.
CN202110534212.8A 2021-05-17 2021-05-17 File system calling method and device, terminal equipment and readable storage medium Active CN113296910B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110534212.8A CN113296910B (en) 2021-05-17 2021-05-17 File system calling method and device, terminal equipment and readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110534212.8A CN113296910B (en) 2021-05-17 2021-05-17 File system calling method and device, terminal equipment and readable storage medium

Publications (2)

Publication Number Publication Date
CN113296910A true CN113296910A (en) 2021-08-24
CN113296910B CN113296910B (en) 2023-12-15

Family

ID=77322388

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110534212.8A Active CN113296910B (en) 2021-05-17 2021-05-17 File system calling method and device, terminal equipment and readable storage medium

Country Status (1)

Country Link
CN (1) CN113296910B (en)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106371934A (en) * 2016-08-25 2017-02-01 成都索贝数码科技股份有限公司 Windows file system driver-based third-party storage protocol file access system and access method
CN106844763A (en) * 2017-02-21 2017-06-13 无锡华云数据技术服务有限公司 A kind of method represented to the Internet media file formula of modifying and its device
CN109002730A (en) * 2018-07-26 2018-12-14 郑州云海信息技术有限公司 A kind of file system directories right management method, device, equipment and storage medium
US20190243559A1 (en) * 2018-02-02 2019-08-08 International Business Machines Corporation Workload and interface cognizant heat-tiered storage
CN110377436A (en) * 2019-07-12 2019-10-25 清华大学 Data storage access method, equipment and the device of persistence memory
CN112698921A (en) * 2021-01-08 2021-04-23 腾讯科技(深圳)有限公司 Logic code operation method and device, computer equipment and storage medium

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106371934A (en) * 2016-08-25 2017-02-01 成都索贝数码科技股份有限公司 Windows file system driver-based third-party storage protocol file access system and access method
CN106844763A (en) * 2017-02-21 2017-06-13 无锡华云数据技术服务有限公司 A kind of method represented to the Internet media file formula of modifying and its device
US20190243559A1 (en) * 2018-02-02 2019-08-08 International Business Machines Corporation Workload and interface cognizant heat-tiered storage
CN109002730A (en) * 2018-07-26 2018-12-14 郑州云海信息技术有限公司 A kind of file system directories right management method, device, equipment and storage medium
CN110377436A (en) * 2019-07-12 2019-10-25 清华大学 Data storage access method, equipment and the device of persistence memory
CN112698921A (en) * 2021-01-08 2021-04-23 腾讯科技(深圳)有限公司 Logic code operation method and device, computer equipment and storage medium

Also Published As

Publication number Publication date
CN113296910B (en) 2023-12-15

Similar Documents

Publication Publication Date Title
US9904527B1 (en) Optimizing API implementer programs using fine-grained code analysis
US9336018B2 (en) Mechanism for class data sharing using extension and application class-loaders
US20200250302A1 (en) Security control method and computer system
US7870443B2 (en) Method to isolate crash of an embedded multi-threaded application to a shared library call without core dump files or debugger
US8966635B2 (en) Software module object analysis
US20090249311A1 (en) Sharing a native module of compiled code using an abstraction module of interpreted code in a virtual machine environment
US20100306766A1 (en) Adding aspects to virtual machine monitors
CN113010265A (en) Pod scheduling method, scheduler, memory plug-in and system
EP2511820A1 (en) Bypassing user mode redirection
US9727390B1 (en) Invoking a firmware function
US9727356B2 (en) Scaling past the java virtual machine thread limit
US11500982B2 (en) Systems and methods for reliably injecting control flow integrity into binaries by tokenizing return addresses
CN113296910A (en) File system calling method and device, terminal equipment and readable storage medium
US8788785B1 (en) Systems and methods for preventing heap-spray attacks
CN114588638A (en) Method for developing game based on Lua language and program development device
CN114691496A (en) Unit testing method, unit testing device, computing equipment and medium
US20170364400A1 (en) Method for debugging static memory corruption
US10936290B2 (en) Compile-time folding of assumed constant values
CN112835865A (en) Application hot deployment system, method and device
US9086895B1 (en) Controlling hardware driver selection
US9208112B1 (en) Permanent allocation of a large host memory
US8135943B1 (en) Method, apparatus, and computer-readable medium for generating a dispatching function
CN113574513A (en) Detecting changes to storage keys for protecting memory
US20130042235A1 (en) Dynamic bootstrap literal processing within a managed runtime environment
US20240045947A1 (en) Function pointer protection

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant