CN113296910B - 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
CN113296910B
CN113296910B CN202110534212.8A CN202110534212A CN113296910B CN 113296910 B CN113296910 B CN 113296910B CN 202110534212 A CN202110534212 A CN 202110534212A CN 113296910 B CN113296910 B CN 113296910B
Authority
CN
China
Prior art keywords
file system
task
interface
running
calling
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.)
Active
Application number
CN202110534212.8A
Other languages
Chinese (zh)
Other versions
CN113296910A (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.)
Shenzhen Ubtech Technology Co ltd
Original Assignee
Shenzhen Ubtech Technology Co ltd
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 Shenzhen Ubtech Technology Co ltd filed Critical Shenzhen Ubtech Technology Co ltd
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

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, terminal equipment and a readable storage medium, wherein the method comprises the following steps: the terminal equipment calls an interface of a preset file system, wherein the interface is obtained by encapsulating the preset file system aiming at an operation task; identifying a handle of the running task through the virtual file system to obtain a class of the running task; and calling an operation function corresponding to the running task in the preset file system according to the class of the running task. The application can solve the problem that when the operating system runs tasks in different languages, the calling of the file system is inconvenient, and can ensure the integrity of the original system architecture and realize the effective access of multiple types of running tasks.

Description

File system calling method and device, terminal equipment and readable storage medium
Technical Field
The present application belongs to the technical field of file system applications, and in particular, relates to a method and apparatus for calling a file system, a terminal device, and a readable storage medium.
Background
A File System (FS) is a method and data structure used by an operating System to clarify files on a storage device or partition, i.e., a software mechanism that organizes, manages, and stores File information on a storage device; the method is mainly responsible for organizing and distributing the space of the file storage device, storing the file, protecting and searching the stored file and the like.
Micro Python is a Python interpreter and runtime system running on top of the microcontroller hardware. Under the framework of the Micro Python system, the adopted file system can be called step by step under the Python language code, and aiming at the parts of other non-Python language codes in the product application, the file system is difficult to call, so that when the operating system runs tasks of different language codes, a plurality of inconveniences exist in the call of the file system, and the integrity of the framework of the original Micro Python system can be even destroyed.
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, which can solve the problem that when an operating system runs tasks in different languages, a plurality of inconveniences exist in the calling of the file system.
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 a category of the running task; and calling an operation function corresponding to the running task in the preset file system according to the class of the running task.
In a possible implementation manner of the first aspect, the interface includes a raw 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 an operation task of a 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 calling the interface of the preset file system includes:
invoking the locked interface of the preset file system; and if the locked interface has no 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, the handle of the running task, and obtaining the class 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 class 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; and 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 restored to the usable state.
In a second aspect, an embodiment of the present application provides a file system calling device, where the device includes:
the first calling unit is used for calling an interface of a preset file system, wherein 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 the virtual file system to obtain the category of the running task;
and the second calling unit is used for calling the operation function corresponding to the running task in the preset file system according to the class 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 the mutual exclusion lock.
In a third aspect, an embodiment of the present application provides a terminal device, the terminal device including 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 one of the first aspects when the computer program is executed.
In a fourth aspect, embodiments of the present application provide a computer readable storage medium storing a computer program which, when executed by a processor, implements the method of any of the first aspects.
In a fifth aspect, an embodiment of the application provides a computer program product for, when run on a terminal device, causing the terminal device to perform the method of any of the first aspects described above.
It will be appreciated that the advantages of the second to fifth aspects described above may be referred to in the description related to the first aspect, and will not be described here again.
Compared with the prior art, the embodiment of the application has the beneficial effects that: according to the embodiment of the application, the terminal equipment invokes an interface of the preset file system, wherein the interface is obtained by encapsulating the preset file system aiming at an operation task; identifying a handle of the running task through the virtual file system to obtain a class of the running task; according to the category of the running task, calling an operation function corresponding to the running task in a preset file system; the embodiment of the application 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 called inconveniently when the operating system runs tasks in different languages is solved, and the integrity of the original running system architecture is prevented from being damaged; the method has the advantages that the structural integrity of the original running system is ensured, and meanwhile, the effective access of multiple types of running tasks is realized; has stronger usability and practicability.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic diagram of a system architecture according to an embodiment of the present application;
FIG. 2 is a flowchart illustrating a method for invoking a file system according to an embodiment of the present application;
FIG. 3 is a flow chart of an overall method according to another embodiment of the present application;
FIG. 4 is a schematic diagram of a file system calling device 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 the particular system architecture, 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 should 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 the present specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.
As used in the present description and the appended claims, the term "if" may be interpreted as "when..once" or "in response to a determination" or "in response to detection" depending on the context. Similarly, the phrase "if a determination" or "if a [ described condition or event ] is detected" may be interpreted in the context of meaning "upon determination" or "in response to determination" or "upon detection of a [ described condition or event ]" or "in response to detection of a [ described condition or event ]".
Furthermore, the terms "first," "second," "third," and the like in the description of the present specification and in the appended claims, are used for distinguishing between descriptions and not necessarily for indicating or implying a relative importance.
Reference in the 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 application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.
Micro Python is a complete software implementation of Python3 programming language, written in C language, python interpreters and runtime systems that can run on top of microcontroller hardware. The conventional file system of MicroPython uses a file configuration table (File Allocation Table, FAT) file system, and since the FAT file system is a centralized index type file system, the FAT file system does not have a function of balancing loss, is not suitable for directly operating on a flash of a nonvolatile storage medium, and the storage medium often used by a microcontroller is the flash. Therefore, it is desirable to select a file system suitable for use in an embedded microcontroller, for migration into MicroPython, such as the littleFS file system.
As application complexity increases, so does the task to which the application corresponds. However, through the file system transplanted to the Micro Python system architecture, the file system needs to be called step by step under the Python language code; running tasks (e.g., user function tasks) for other non-Micro Python language code are more difficult to implement to call the file system. Because of the self-integrity of the Micro Python system framework, no interface is provided externally that allows user function tasks (C language code tasks) to call the file system. Because the user function task has the possibility of accessing the file system in other language code layers, if the user function task passes through the original call flow, the self-integrity of the MicroPython system architecture can be possibly damaged; thus, when the operating system runs tasks of codes in different languages, a plurality of inconveniences exist in calling the file system.
In addition, the file system transplanted to the Micro Python system architecture cannot guarantee thread security, and how to avoid the phenomenon that different task threads (such as task threads of the Micro Python framework and threads of user function tasks) operate the same file at the same time to cause file damage is also a technical problem to be solved by the embodiment of the application.
Referring to fig. 1, a system architecture diagram according to an embodiment of the present application is provided. In the embedded microcontroller, a default file system littleFS with balanced wear is adopted based on the runtime system of the Micro Python framework. 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 a C language code is encapsulated for the preset file system, so that a user function task can access the preset file system at the C language code level. As shown in fig. 1, in the embedded microcontroller, the application layer is an architecture layer for running tasks; the preset file system provided by the embodiment of the application can support a Micro Python task or a C language user function task, namely, the Micro Python task or the C language user function task can call an interface API written by a C language code of the preset file system.
The littleFS file system is mainly applied to microcontrollers and flash, is an embedded file system, has the characteristics of power failure recovery, erasing and writing balance, storage space saving and the like, and is very suitable for being used in embedded microcontrollers. And transplanting the littleFS to a Micro Python runtime system to realize operations such as reading, writing, erasing and the like of the Flash of the storage device. In addition, the Runtime system is a running mode which is in danger of compiling and interpreting, the compiler firstly compiles the source code into an intermediate code, and the Runtime (run) acts as an Interpreter (Interpreter) to interpret the intermediate code when executing; i.e., the environment in which the semi-compiled code is run on the target machine.
The storage device Flash stores a drive function for performing operations such as reading, writing, erasing and synchronization on a preset file system littleFS; and simultaneously, a Flash operation entry function of the Micro Python kernel is stored, so that when the running task is a Micro Python task, the step-by-step downward call of a preset file system littleFS is realized under the Micro Python frame. When the running task accesses the littleFS file system, the class of the running task is identified, and different operation functions are called based on the class of the running task, so that the possibility that the kernel architecture of the Micro Python is damaged in the process of accessing the other user function tasks can be avoided.
In addition, under the operating system of the embedded microcontroller, the bottom layer simulates threads through the process, the threads are execution flows in the process, and for the multithreaded process, the resources of the file system are mostly shared, so that the situation that a plurality of threads running tasks access the same resource of the file system at the same time is likely to occur, and the situation that one thread accesses the same resource of the file system when the other thread accesses the same resource is likely to occur. To ensure the security of threads accessing the same littleFS file system resources, the access interface API (original interface) of the littleFS is further encapsulated, so as to obtain a locked interface with a mutual exclusion lock. When a running task initiates a call to a locked interface, if other threads lock the interface or initiate the call while other threads exist, a waiting state is entered until the mutual exclusion lock releases the locked interface after the task of the last thread is executed, the call to the locked interface is timely performed, and the locked interface is locked, so that the possibility that the file system resources are damaged due to the fact that different threads access the same file system resources can be avoided.
According to the embodiment of the application, on the premise of not damaging the self-integrity of the Micro Python frame, an interface (C interface) for accessing the littleF S file system can be provided for a user function task at a C language code layer when the littleF S 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 frame is ensured; meanwhile, the security of threads for simultaneously accessing the same file system resources by the Micro Python task and the user function task is ensured through the mutex lock packaged by the original interface of the littleFS file system.
The following describes the flow steps of the file system calling method provided by the application through a specific embodiment.
Referring to fig. 2, a flowchart of a file system call method according to an embodiment of the present application is shown. The method may comprise the steps of:
step S201, the main terminal device calls an interface of a preset file system, wherein the interface is obtained by packaging the preset file system aiming at an operation task.
In some embodiments, the preset file system is a file system of a Micro Python runtime system architecture ported to an embedded microcontroller, which may be, for example, a littleFS file system. The running tasks may include tasks of different language codes, which may correspond to different threads. The file system interface is packaged into interfaces which can be called by the tasks of the language codes aiming at the task types of the different language codes. For example, under the architecture of the Micro Python runtime system, the interface of the transplanted littleFS file system is encapsulated as the interface of the C language code (C interface), and different types of running tasks can call the C interface of the littleFS file system.
In addition, the running tasks may include Micro Python tasks or user function tasks; 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, not only the access of the Micro Python task but also the access of the user function task can be realized.
By way of example, the type of file system interface may also be extended according to the type of running task, and as the complexity of application functions increases, access to file system resources by different types of tasks may be supported.
In some embodiments, the interfaces may include a raw 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 terminal equipment encapsulates the preset file system to obtain an original interface corresponding to the running task of the preset language type; and the terminal equipment locks and encapsulates the original interface of the preset file system to obtain a locked interface with the 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 of file damage caused by the fact that running tasks of different threads of outgoing lines access the same resources of a file system, terminal equipment locks and encapsulates an original C interface again to obtain a locked interface with a mutual exclusion lock.
Illustratively, the code form of the locked interface with the exclusive lock obtained by locking and packaging the original interface can be expressed as follows:
wherein "type" indicates the type of the interface, for example, an interface of types such as "open", "close", etc., and the type in lfs _mutex_xxx (type....
In addition, the naming of the functions, the interface symbols and the like can be set in a self-defining way, and the original interface can be packaged into the locked interface with the structure.
It should be noted that, through further locking and packaging the original C interface, the obtained locked interface with the mutual exclusive lock is changed from the original direct calling of the original interface by the Micro Python task code to the direct calling of the locked interface; the code of the user function task also directly invokes the keyed interface.
Referring to fig. 3, another embodiment of the present application provides a flow chart of the overall method. The steps of the embodiment of fig. 2 are further refined.
In some embodiments, the terminal device invokes an interface of a preset file system, including:
step S301, a terminal device calls a locked interface of a preset file system;
step S302, if the locked interface has no corresponding running task, the terminal equipment continues to call the original interface of the preset file system.
In some embodiments, the Micro Python task code directly invokes the original interface instead of directly invoking the locked interface; the code of the user function task also directly invokes the keyed interface. If the locked interface is in a release state currently, 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 corresponding follow-up flow is executed by calling the original interface.
If the locked interface is currently in the locked state, it indicates that the existing running task accesses the file system and locks the locked interface, so that when other running tasks call the locked interface, the file system cannot be directly accessed, the locked interface needs to be released after the program is executed, the locked interface is restored to the accessible state, the other running tasks can access and call, and the other running tasks also lock the locked interface when accessing. The original interface and the locked interface after locking and packaging can be interfaces of the C language layer.
In addition, different running tasks correspond to different threads, and the original interface (C interface) is further locked and packaged into a locked interface with a mutual exclusion lock, so that the defect that the running tasks of different threads access the same file system resource at the same time to cause file damage can be avoided, and the safety of accessing the file system by the multithreaded running tasks is ensured.
In step S202, the terminal device identifies a handle of the running task through the virtual file system, and obtains a class of the running task.
In some embodiments, the architecture of the Micro Python runtime system has a virtual file system, and the handle of the current running task can be acquired through the function of the virtual file system, so that the type of the running task is judged according to the content of the handle.
The virtual file system may be expressed as vfs_lfsx.c, and functions of the virtual file system under the Micro Python framework may include operation driving functions such as reading, writing, erasing, and synchronization. The handle may be an entire length of data that is a unique identification of an access object and corresponds to the access object one-to-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 the self-contained function through the virtual file system to obtain the 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 terminal device identifies a handle of the running task through the virtual file system, and obtains a class of the running task, including:
step S303, the terminal equipment obtains a handle of the running task by calling an operation function of the virtual file system;
in step S304, the terminal device determines the type of the running task according to the target object in the handle.
In some embodiments, the processor employed by the terminal device may be an embedded microcontroller, and the memory uses Flash. In the terminal device, based on the running environment of Micro Python, a virtual file system (which may be expressed as vfs_lfsx.c) is contained, the virtual file system vfs is implemented based on an oofatfs database, and the oofatfs database is a file system fatfs from an open source, i.e. the whole virtual file system vfs is extended based on the file system fatfs.
The virtual file system is provided with read, write, erase and synchronous operation functions. After the running task accesses the original interface, the virtual file system calls the self-contained function to obtain the handle of the running task, judges the type of the running task according to the target object accessed by the handle, returns the handle of the running task, and obtains the class result of the running task. The target object may be a file or a resource in the memory Flash.
The class result of the running task may be, for example, a Micro Python task or a user function task (C language code level).
Step S203, the terminal equipment calls an operation function corresponding to the running task in the preset file system according to the class of the running task.
In some embodiments, in order to avoid that the access of other user function tasks damages the self-completion of the Micro Python running environment in the terminal device, branches of access flows are set for different types of running 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 the memory Flash can be directly called, a Flash operation entry function of a Micro Python kernel is not needed, and modification of a Micro Python kernel code is not needed, so that other types of running tasks except the Micro Python task can be successfully accessed to resources of a file system under the condition that the self-integrity of the Micro Python architecture is ensured.
For example, in a Micro Python running environment, if the running task is a Micro Python task, flash operation functions, such as Flash operation entry functions, that are gradually and downwardly transferred to the Micro Python kernel under Python code may be used.
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 class 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 a 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 the C language level and the second language code task may be an execution 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 flow nodes, the running tasks of non-Python language codes are prevented from damaging the architecture of a Micro Python kernel, modification of the Micro Python kernel codes is avoided, and meanwhile the probability that other running tasks are involved in the Micro Python kernel architecture and faults such as running errors or shutdown are easy to occur is reduced.
For example, if the type of the running task is a user function task based on a C language code, the Flash operation driving function of the file system may be directly called; if the type of the running task is a Micro Python task based on the Python language code, a Flash operation entry function of the Micro Python kernel can be called, and finally, a Flash operation driving function can be further called. Therefore, the call chain passing through the Micro Python kernel entrance and the call chain not passing through the Micro Python kernel entrance are divided, and the integrity of a Micro Python frame 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 call method further comprises:
step S307, after the terminal device executes the operation task, the locked interface is released, so that the locked interface is restored to the usable state.
In some embodiments, when executing the current running task, 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 can be accessed after waiting for the locked interface to be unlocked. Releasing the locked interface after the current running task is executed, so that the locked interface is 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 embodiment of the application, the terminal equipment identifies the running task and determines the type of the running task, so that a 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 the operating system runs tasks in different languages is solved, and the integrity of the original running system architecture is prevented from being damaged; the method and the system realize the effective access of multiple types of running tasks while guaranteeing the integrity of the original running system architecture.
According to the embodiment of the application, on the premise of not damaging the self-integrity of the Micro Python frame, an interface (C interface) for accessing the littleF S file system can be provided for a user function task at a C language code layer when the littleF S 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 frame is ensured; meanwhile, the security of the simultaneous access of the Micro Python task and the user function task to the same file system resource is ensured through the mutex lock packaged by the interface of the littleF file system.
It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic, and should not limit the implementation process of the embodiment of the present application.
Corresponding to the file system calling method in the above embodiment, the embodiment of the present application further provides a file system calling device, as shown in fig. 4, where the device includes:
the first calling unit 41 is configured to call an interface of the preset file system, where the interface is obtained by encapsulating the preset file system for an operation task;
an identifying unit 42, configured to identify a handle of the running task through the virtual file system, and obtain a class of the running task;
and the second calling unit 43 is used for calling the operation function corresponding to the running task in the preset file system according to the class of the running task.
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 the mutual exclusion lock.
According to the embodiment of the application, on the premise of not damaging the self-integrity of the Micro Python frame, an interface (C interface) for accessing the littleF S file system can be provided for a user function task at a C language code layer when the littleF S 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 frame is ensured; meanwhile, the security of the simultaneous access of the Micro Python task and the user function task to the same file system resource is ensured through the mutex lock packaged by the interface of the littleF file system.
It should be noted that, because the content of information interaction and execution process between the above devices/units is based on the same concept as the method embodiment of the present application, specific functions and technical effects thereof may be referred to in the method embodiment section, and will not be described herein.
It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions. The functional units and modules in the embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit, where the integrated units may be implemented in a form of hardware or a form of a software functional unit. In addition, the specific names of the functional units and modules are only for distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working process of the units and modules in the above system may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.
Embodiments of the present application also provide a computer-readable storage medium storing a computer program which, when executed by a processor, implements the steps of the respective method embodiments described above.
The embodiments of the present application provide a computer program product which, when run on a terminal device, causes the terminal device to perform the steps of the method embodiments described above.
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 executable on the at least one processor 50, the processor 50 implementing the steps in any of the various file system call method embodiments described above when executing the computer program 52.
The terminal device 5 may be a computing device such as a desktop computer, a notebook computer, a palm computer, a cloud server, etc. The terminal device 5 may include, but is not limited to, a processor 50, a memory 51. It will be appreciated by those skilled in the art that fig. 5 is merely an example of the terminal device 5 and is not meant to be limiting as the terminal device 5, and may include more or fewer components than shown, or may combine certain components, or different components, such as may also include input-output devices, network access devices, etc.
The processor 50 may be a central processing unit (Central Processing Unit, CPU), the processor 50 may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. 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 in other embodiments also be an external storage device of the terminal device 5, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card) or 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, application programs, boot loader (BootLoader), data, other programs, etc., 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 units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application may implement all or part of the flow of the method of the above embodiments, and may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the computer program may implement the steps of each of the method embodiments described above. Wherein the computer program comprises computer program code which may be in source code form, object code form, 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 device/terminal apparatus, recording medium, computer Memory, read-Only Memory (ROM), random access Memory (RAM, random Access Memory), electrical carrier signals, telecommunications signals, and software distribution media. Such as a U-disk, removable hard disk, magnetic or optical disk, etc. In some jurisdictions, computer readable media may not be electrical carrier signals and telecommunications signals in accordance with legislation and patent practice.
In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.
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 solution. 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 manners. For example, the apparatus/device embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.
The units described as separate units may or may not be physically separate, and units shown 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 may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
The above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.

Claims (9)

1. A method for invoking 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 a category of the running task;
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, an operation entry function corresponding to the second language code task in the preset file system is called, and the operation driving function is called according to the operation entry function;
the interface is used for encapsulating the file system interface into an interface which can be called by each language code task aiming at the task types of different language codes.
2. The method of claim 1, wherein the interface comprises a raw 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 an operation task of a 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 the invoking the interface of the preset file system comprises:
invoking the locked interface of the preset file system;
and if the locked interface has no corresponding running task, continuing to call the original interface of the preset file system.
4. The method of claim 1, wherein the identifying, by the virtual file system, the handle of the running task to obtain the class 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. A method according to 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 restored to the usable state.
6. A file system calling device, said device comprising:
the first calling unit is used for calling an interface of a preset file system, wherein 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 the virtual file system to obtain the category of the running task;
the second calling unit is used for calling an operation driving function corresponding to the first language code task in the preset file system if the running task is the first language code task; if the running task is a second language code task, an operation entry function corresponding to the second language code task in the preset file system is called, and the operation driving function is called according to the operation entry function;
the interface is used for encapsulating the file system interface into an interface which can be called by each language code task aiming at the task types of different language codes.
7. The apparatus of claim 6, 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 the mutual exclusion lock.
8. A terminal device, characterized in that it comprises a memory, a processor and a computer program stored in the memory and executable on the processor, which processor, when executing the computer program, implements the method according to any of claims 1 to 5.
9. A computer readable storage medium storing a computer program, characterized in that the computer program when executed by a processor implements the method according to any one of claims 1 to 5.
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 CN113296910A (en) 2021-08-24
CN113296910B true 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 (5)

* 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
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

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11662910B2 (en) * 2018-02-02 2023-05-30 International Business Machines Corporation Workload and interface cognizant heat-tiered storage

Patent Citations (5)

* 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
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
CN113296910A (en) 2021-08-24

Similar Documents

Publication Publication Date Title
US9904527B1 (en) Optimizing API implementer programs using fine-grained code analysis
US11687645B2 (en) Security control method and computer system
US10489187B2 (en) Systems and methods for auditing a virtual machine
CN105190570B (en) Memory for the integrity protection of virtual machine is examined oneself engine
US9336018B2 (en) Mechanism for class data sharing using extension and application class-loaders
US8484641B2 (en) Implementing a versioned virtualized application runtime environment
US20170286673A1 (en) Malware-Resistant Application Control in Virtualized Environments
US20170308484A1 (en) Systems And Methods For Dynamically Protecting A Stack From Below The Operating System
US8429648B2 (en) Method and apparatus to service a software generated trap received by a virtual machine monitor
JP2016515748A (en) System and method for replacing application methods at runtime
CN112035272A (en) Method and device for interprocess communication and computer equipment
CN113010265A (en) Pod scheduling method, scheduler, memory plug-in and system
US20220004636A1 (en) Statistical detection of firmware-level compromises
US20120331489A1 (en) Bypassing user mode redirection
US9632816B2 (en) Scaling past the Java virtual machine thread limit
CN111444504A (en) Method and device for automatically identifying malicious codes during software running
CN113296910B (en) File system calling method and device, terminal equipment and readable storage medium
US8788785B1 (en) Systems and methods for preventing heap-spray attacks
US11586727B2 (en) Systems and methods for preventing kernel stalling attacks
CN114691496A (en) Unit testing method, unit testing device, computing equipment and medium
US11074200B2 (en) Use-after-free exploit prevention architecture
US10095849B1 (en) Tag-based programming interface authentication
US11989572B2 (en) Computer system enabled with runtime software module tracking
CN113806714A (en) Safe transmission method and device for white list information of application program
CN116010100A (en) Contract calling method, device, equipment and storage medium in block chain system

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