WO2022222809A1 - 功能组件处理方法、介质、设备和操作系统 - Google Patents

功能组件处理方法、介质、设备和操作系统 Download PDF

Info

Publication number
WO2022222809A1
WO2022222809A1 PCT/CN2022/086515 CN2022086515W WO2022222809A1 WO 2022222809 A1 WO2022222809 A1 WO 2022222809A1 CN 2022086515 W CN2022086515 W CN 2022086515W WO 2022222809 A1 WO2022222809 A1 WO 2022222809A1
Authority
WO
WIPO (PCT)
Prior art keywords
functional component
target
user
kernel
configuration
Prior art date
Application number
PCT/CN2022/086515
Other languages
English (en)
French (fr)
Inventor
谷良增
毛熠璐
Original Assignee
阿里巴巴（中国）有限公司
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 阿里巴巴（中国）有限公司 filed Critical 阿里巴巴（中国）有限公司
Publication of WO2022222809A1 publication Critical patent/WO2022222809A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services

Definitions

  • the present invention relates to the field of computer technology, and in particular, to a method, medium, device and operating system for processing functional components.
  • the operating system will contain the operating system kernel, which can be divided into microkernel (Micro Kernel) and macro kernel (Monolithic Kernel) according to the architecture of the operating system kernel.
  • microkernel Micro Kernel
  • macro kernel Monolithic Kernel
  • Figures 1 and 2 illustrate a typical structure of a macrokernel and a microkernel, respectively.
  • functions in the operating system such as process management, memory management, device management, file system, network protocol, clock management, interrupt processing, primitives (such as CPU switching, device drivers, etc.) Components are all set up in the operating system kernel.
  • functional components such as process management, memory management, device management, file system, network protocol, etc. in the operating system are set in the user mode (user space) outside the operating system kernel , and some functional components involved in core operations, such as clock management, interrupt processing, and primitives, are set in the operating system kernel.
  • Embodiments of the present invention provide a method, medium, device and operating system for processing functional components, so as to realize flexible configuration of the operating system by a user.
  • an embodiment of the present invention provides a method for processing functional components.
  • An operating system includes a kernel and a user space.
  • a virtual file system is configured in each user process of the kernel and the user space. The method includes:
  • the configuration request includes an identifier of a target functional component in the operating system and a target configuration location of the target functional component in the operating system;
  • the target functional component configuring the target functional component to the target configuration location, where the target configuration location is located in the user space or the kernel;
  • the registration information of the target functional component is generated in the virtual file system corresponding to the target configuration location.
  • an embodiment of the present invention provides an apparatus for processing functional components.
  • An operating system includes a kernel and a user space.
  • a virtual file system is configured in each user process of the kernel and the user space.
  • the apparatus includes:
  • a receiving module for obtaining a configuration request, the configuration request including the identification of the target functional component in the operating system and the target configuration position of the target functional component in the operating system;
  • a configuration module configured to configure the target functional component to the target configuration location, where the target configuration location is located in the user space or the kernel; generate a registration of the target functional component in the virtual file system corresponding to the target configuration location information.
  • an embodiment of the present invention provides a method for processing functional components.
  • the operating system includes a kernel and a user space, and each user process in the kernel and the user space is configured with a virtual file system; the method includes:
  • the target functional component to a second configuration location
  • the first configuration location and the second configuration location are respectively located in the user process or the kernel in the user space, the first configuration location and the The two configuration locations are different;
  • the registration information of the target functional component is generated in the virtual file system corresponding to the second configuration location.
  • an embodiment of the present invention provides a method for processing functional components, the operating system includes a kernel and a user space, and the method includes:
  • the target configuration location of the target functional component is any one of the following: the kernel, the first user process, the user space second user process;
  • an embodiment of the present invention provides an electronic device, including a processor, a memory, and an operating system, wherein executable code is stored on the memory, and when the executable code is executed by the processor, the The processor may at least implement the functional component processing method in the first aspect or the third aspect or the fifth aspect.
  • an embodiment of the present invention provides a non-transitory machine-readable storage medium, where executable code is stored on the non-transitory machine-readable storage medium, and when the executable code is executed by a processor of an electronic device When executed, the processor can at least implement the functional component processing method in the first aspect or the third aspect or the fifth aspect.
  • an embodiment of the present invention provides an operating system, including:
  • a virtual file system is configured in each user process of the user space;
  • a path management module is configured in the user space;
  • a virtual file system is configured in the kernel
  • the target user process in the user space includes at least one first functional component configured by the user, and the virtual file system in the target user process includes first registration information of the at least one first functional component;
  • the path management module includes second registration information of functional components configured in each user process in the user space;
  • the kernel includes at least one second functional component configured by the user, and the virtual file system in the kernel includes registration information of the at least one second functional component.
  • a virtual file system (Virtual File System, VFS for short) is set in the kernel of the operating system and each user process in the user space to support the user's demand for each functional component in the operating system.
  • VFS Virtual File System
  • Flexible configuration Different from the traditional fixed configuration solution of the operating system kernel, based on the solution provided in the embodiment of the present invention, the user can configure the functional components included in the operating system as needed whether their location is in the kernel of the operating system or in the user. in a user process in the space.
  • the target functional component when receiving a user-triggered configuration request including the identifier of the target functional component and the target configuration location of the target functional component, on the one hand, configure the target functional component to the target configuration location, and the target configuration location is located in the user process of the user space Or the kernel, on the other hand, the registration information of the target functional component is generated in the VFS corresponding to the target configuration location, thus completing the configuration of the functional component.
  • Fig. 1 is the structural representation of a traditional macro kernel
  • Fig. 2 is the structural representation of a kind of traditional microkernel
  • FIG. 3a is a schematic diagram of an operating system architecture provided by an embodiment of the present invention.
  • 3b is a schematic diagram of an operating system configuration and a calling scenario provided by an embodiment of the present invention.
  • 4a is a flowchart of a method for processing a functional component provided by an embodiment of the present invention.
  • Fig. 4b is a schematic diagram of a configuration interface corresponding to the processing method of the functional component shown in Fig. 4a;
  • 5a is a flowchart of a method for processing a functional component provided by another embodiment of the present invention.
  • Fig. 5b is a schematic diagram of a configuration interface corresponding to the functional component processing method shown in Fig. 5a;
  • FIG. 6 is a flowchart of a method for invoking a functional component provided by an embodiment of the present invention.
  • FIG. 7a is a schematic diagram of a functional component invocation scenario provided by an embodiment of the present invention.
  • FIG. 7b is a schematic diagram of a functional component invocation scenario provided by another embodiment of the present invention.
  • FIG. 7c is a schematic diagram of a functional component invocation scenario provided by another embodiment of the present invention.
  • FIG. 8 is a schematic structural diagram of a functional component processing apparatus according to an embodiment of the present invention.
  • FIG. 9 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.
  • the functional component processing method provided by the embodiment of the present invention can enable a user to flexibly configure the operating system in the device, or configure the kernel of the operating system as required. Specifically, it is a configuration location where functional components included in the operating system can be configured.
  • the architecture of the operating system is divided into kernel mode and user mode, or kernel and user space. Therefore, the above configuration locations are divided into two categories: kernel and user space. Among them, in the user space, specifically configured in the user process of the user space.
  • a functional component in this article refers to a module in an operating system that provides a certain function.
  • the functional components included in the operating system are divided into basic components (or core components) and non-basic components (or non-core components), such as clock management, interrupt processing, primitives and other functional components as basic components, such as process management, memory Management, device management, file system, network protocol and other functional components are regarded as non-basic components, then it can be considered that under the traditional macro-kernel architecture, basic components and non-basic components are fixedly configured in the kernel and are in kernel state; Under the traditional microkernel architecture, the basic components are fixedly configured in the kernel and are in the kernel state, while the non-basic components are fixedly configured in the user space and are in the user state.
  • the basic components can still be configured in the kernel, and the user can flexibly configure the non-basic components as needed.
  • some non-basic components can be configured in the user space, and other Some non-basic components are configured in the kernel, and some functions of a non-basic component can be configured in the kernel and another part of the functions can be configured in the user space.
  • the user can also flexibly set the configuration location of the basic components as needed.
  • FIG. 3a is a schematic diagram of an operating system architecture provided by an embodiment of the present invention.
  • the operating system includes: a kernel and a user space.
  • a virtual file system is configured in each user process in the user space, and a virtual file system is also configured in the kernel.
  • a path management (Path Manager) module is configured in the user space, which is used to uniformly manage the registration information of the functional components included in all user processes in the user space.
  • a virtual file system is configured in the kernel, which is in the kernel mode; each user process in the user space is configured with a virtual file system in the user mode.
  • the virtual file system set in the kernel is represented as: Kernel_VFS.
  • the virtual file system included in user process A is represented as: A0S_VFSa
  • the virtual file system included in user process B is represented as: A0S_VFSb
  • the user The virtual file system contained in process C is represented as: A0S_VFSc.
  • each user process will contain a standard function library, such as LIBC shown in the figure, in which a virtual file system is set. Therefore, different user processes can implement the setting of the local virtual file system by loading the function library including the virtual file system. After that, based on the configuration operation of the functional component by the user, the corresponding registration information may be written into the virtual file system at the corresponding configuration location.
  • a standard function library such as LIBC shown in the figure
  • the path management module is set in the user process C, in fact, not limited to this, the path management module may also run in other user processes, such as a management process.
  • the virtual file system in a user process only stores the registration information of the functional components registered to the user process, while the path management module stores the registration information of the functional components registered to each user process, that is, all The registration information of the functional components registered to the user mode. Moreover, for the same functional component, the registration information corresponding to the virtual file system of a user process is different from the registration information corresponding to the path management module.
  • the information contained in the different virtual file systems mentioned above is different, and it can be considered that the registration information of the functional components contained in the different virtual file systems is different.
  • the user can flexibly configure the configuration positions of various functional components in the operating system as required.
  • the target user process in the user space will contain the at least one user-configured process.
  • a first functional component, and the virtual file system in the target user process will contain the first registration information of the at least one first functional component.
  • the second registration information of the at least one first functional component also needs to be written into the path management module.
  • the difference between the first registration information and the second registration information is mainly reflected in that the calling information of the first functional component contained in the two registration information is different, that is, corresponding to two different calling methods.
  • the registration information of a function module will contain the call information corresponding to the function module, and the corresponding call information will also be different if the configuration location of the function module is different.
  • the composition of specific registration information will be specifically described in subsequent embodiments.
  • the kernel will contain the at least one second functional component configured by the user, and the virtual file system in the kernel will contain the at least one second functional component. Registration information of at least one second functional component.
  • the example in Figure 3a is that the user configures the two functional components of device driver 1 and flash memory (Flash) into the same user process A, configures the two functional components of the network protocol and network card into the same user process B, and configures the file System (File System) This functional component is configured in the user process C.
  • the user configures the device driver 2, a functional component, into the kernel.
  • the device driver 1 and the device driver 2 refer to functional components that respectively provide some device driving functions, and it can be considered that the traditional device driving functions are divided into two functional components to provide.
  • basic functional components such as clock management, interrupt handling, etc. are configured in the kernel.
  • the virtual file system A0S_VFSa in the user process A will contain the registration information of the two functional components of device driver 1 and flash memory
  • the virtual file system A0S_VFSb in the user process B will contain the two network protocols and network cards.
  • the registration information of the functional component, the virtual file system A0S_VFSc in the user process C will contain the registration information of the functional component of the file system
  • the virtual file system Kernel_VFS in the kernel will contain the functional components such as device driver 2, clock management, interrupt handling, etc. registration information.
  • up and down means that functional components can be configured to run in kernel mode or user mode, and are no longer limited by the fixed setting results under the traditional macro-kernel and micro-kernel architectures. For example, assuming that a functional component can only run in the user mode under the traditional microkernel architecture, based on the solution provided by the embodiment of the present invention, the functional component can be configured to run in the kernel mode.
  • merging means that different functional components can be configured to run in the same user process in the user space, and of course, different functional components can also run in different user processes in the user space. It is no longer limited to the fixed setting results of different functional components under the traditional microkernel architecture that can only run in different user processes.
  • the operating efficiency of the operating system can be improved, because the calling method between different functional components in the same user process can be optimized to use the method of function calling instead of being limited by traditional
  • the way of calling between different functional components can only be done by remote procedure call (Remote Procedure Call, RPC for short).
  • the solutions provided by the embodiments of the present invention can be considered as optimization of the traditional operating system architecture, for ease of understanding, as shown in FIG. 3b, assume the following situation: Assume that in the traditional macro-kernel architecture, the functional component W1, the function The component W2, the functional component W3, and the functional component W4 are all located in the kernel, and it is assumed that the user space includes two user processes, a user process 1 and a user process 2. Under the macro-kernel architecture, for example, if a user program in user process 2 wants to call any one of the above-mentioned four functional components in the kernel, it needs to be called by means of a system call.
  • the user can perform the following optimized configuration on the macro kernel as needed: configure the functional component W2 into the user process 1, configure the functional component W3 into the user process 2, Functional component W1 and functional component W4 are still located in the kernel. Based on the configuration result, the calling method of these four functional components will be changed.
  • the following method embodiments can be executed by a processor in an electronic device, and the electronic device is provided with an operating system, and the operating system includes the user space and the kernel mentioned above. Based on the solutions provided in the following embodiments, users can implement flexible configuration of functional components in the operating system.
  • the electronic device may be a terminal device such as an embedded device, a digital assistant, a robot, etc., but is not limited thereto.
  • Fig. 4a is a flowchart of a method for processing a functional component provided by an embodiment of the present invention. As shown in Fig. 4a, the method may include the following steps:
  • a user wants to configure the operating system of the user equipment on demand during the process of developing or using a certain user equipment, that is, to configure where each functional component in the operating system runs. At this time, the user can trigger the above configuration request.
  • the above-mentioned target functional component is any functional component in the operating system.
  • the user can configure the running location of each functional component included in the operating system.
  • the configuration request carries the identifier of the target functional component and the target configuration location.
  • the target configuration location is the desired target functional component to be used.
  • the configured location is a user process in the kernel or user space.
  • a corresponding configuration interface may be provided for the user, so that the user can trigger the configuration operation through the configuration interface.
  • a configuration interface is exemplarily described below with reference to FIG. 4b.
  • the configuration interface may include the identifiers of functional components included in the operating system, such as the identifiers of functional components such as clock management, interrupt management, device driver, file system, network protocol, etc. shown in the figure.
  • the identifiers of functional components such as clock management, interrupt management, device driver, file system, network protocol, etc. shown in the figure.
  • there are multiple options for configuration locations in the configuration interface which mainly include two types of options: the first option is the kernel, and the second option is the user process in the user space.
  • the second option may specifically be: these three user processes. That is, all selectable configuration locations can be presented in the configuration item. For each functional component, the user can select the corresponding configuration location as needed, and the configuration result is shown in Figure 4b.
  • the user can trigger the above configuration process in the process of compiling the operating system.
  • the code of the target functional component needs to be compiled to the target configuration location, and the target functional component needs to be started to initialize the component.
  • the target configuration location is the kernel
  • it is also necessary to complete the registration process of the target functional component that is, to register the target functional component in the virtual file system corresponding to the target configuration location.
  • the registration information of the target functional component generated in the virtual file system corresponding to the target configuration location will be used in the process of calling the target functional component.
  • the following describes the differences in the information that needs to be registered when the target functional components are configured to different configuration locations according to the differences in the target configuration locations of the target functional components.
  • the first virtual file system refers to a virtual file system located in the first user process, that is, the file path of the target functional component and the callback function related information need to be registered in the first virtual file system.
  • the file path refers to the storage path or reference path corresponding to the target functional component, which can be obtained automatically when the target functional component is configured to the target configuration location; the relevant information of the callback function may include the callback function pointer and function parameters and other information.
  • the main use here is the callback function pointer.
  • the target functional component When the target configuration location of the target functional component is located in the user space, in addition to registering the target functional component in the first virtual file system, the target functional component also needs to be registered in the path management module in the user space. Specifically, the file path and RPC_ID corresponding to the target functional component need to be written in the path management module in the user space, that is, the remote procedure call identifier.
  • the above takes the target functional component as an example to describe its registration process in the first user process in the user space.
  • the user may also configure other functional components to the first user process, then based on the above registration process, the first user process will eventually be configured with multiple functional components.
  • the first virtual The file system will also contain information about the respective file paths and callback functions of these multiple functional components, and the path management module will also contain the respective file paths and RPC_IDs of these multiple functional components.
  • users can configure multiple functional components with a collocation relationship into the same user process in the user space.
  • the function call method can be used to realize the implementation, so as to improve the efficiency.
  • Scenario 2 Assuming that the target configuration location is the kernel, at this time, it is necessary to write the file path corresponding to the target functional component and the relevant information of the callback function in the second virtual file system (ie, Kernel_VFS) in the kernel.
  • the relevant information of the callback function may include the callback function pointer and function parameters.
  • the user can set the configuration positions of different functional components according to their own experience.
  • some configuration suggestions can also be provided to the user, so that the user can complete the configuration of the functional components with reference to the configuration suggestions.
  • the functional component configuration solution provided by the embodiments of the present invention will change the architecture of the operating system, that is, it is equivalent to optimizing the operating system of the traditional macro-kernel or micro-kernel architecture, and the optimization is mainly reflected in the functions in the operating system
  • the configuration position of the component changes. Therefore, on the basis that the virtual file system is configured in the kernel of the operating system and each user process in the user space, the configuration process of the functional component can also be described as:
  • Configuring the target functional component to a second configuration position, the first configuration position and the second configuration position are respectively located in the user process or the kernel of the user space, and the first configuration position and the second configuration position are different;
  • the registration information of the target functional component is generated in the virtual file system corresponding to the second configuration location.
  • the target functional component is any functional component included in the operating system.
  • first configuration location and the second configuration location are respectively located in the user process or kernel of the user space, and the first configuration location and the second configuration location are different, which means: if the first configuration location is located in a user process in the user space, then The second configuration location is located in the kernel; if the first configuration location is located in the kernel, the second configuration location is located in a user process in the user space.
  • the optimization of the operating system architecture by the above configuration process is mainly reflected in the following: first, a VFS is provided in the kernel and each user process to write the relevant registration information of the local functional components to provide a prerequisite for the subsequent invocation of the functional components; second, The target functional component originally located in the first configuration position is switched and configured to the second configuration position, that is, the functional component is switched from the kernel state to the user state, or from the user state to the kernel state.
  • a functional component is divided into more fine-grained components, such as splitting into multiple sub-components according to functions, then according to the above configuration scheme, some of the sub-components can be configured in the user mode, and the remaining sub-components can be configured in the user mode. Some subcomponents are configured in kernel mode.
  • Fig. 5a is a flowchart of a method for processing a functional component provided by another embodiment of the present invention. As shown in Fig. 5a, the method may include the following steps:
  • a configuration request from a user includes an identifier of a target functional component in the operating system and a target configuration location of the target functional component in the operating system, where the target configuration location is located in a user process or kernel in user space.
  • a configuration suggestion may be given in combination with some parameter information of the device for the user's reference.
  • the target configuration location of the target functional component in the above configuration request may be the recommended configuration location determined by the user after adopting the configuration suggestion , or another configuration location determined by the user without adopting the configuration suggestion.
  • the parameter information of the device may include, but is not limited to, one or more kinds of information such as the type of application scenario, the processing capability of the device, and the like.
  • the application scenario type may be: a usage scenario of a device with the above-mentioned operating system installed.
  • the device may be an intelligent robot applied in a man-machine dialogue scenario, a detection device applied in a production workshop, or a vehicle-mounted terminal applied in a vehicle.
  • the main tasks that devices in different application scenarios need to complete are different.
  • the main task of the intelligent robot in the man-machine dialogue scene is to complete the intelligent question and answer with the user;
  • the main task of the detection equipment in the production workshop scene is to detect some indicators in the production environment;
  • the main task of the vehicle terminal is to provide Navigation related services.
  • the frequency of use of different functional components in the operating system may also be different for different tasks.
  • the configuration suggestions given are as follows:
  • the functional component M1, the functional component M2, and the functional component M3 are configured in the user process U1
  • the functional component M4 is configured in the user process U2
  • the functional component M5 is configured in the kernel.
  • the functional component M1 and the functional component M3 are configured in the user process U1, the functional component M2 is configured in the user process U2, and the functional component M4 and the functional component M5 are configured in the kernel.
  • the parameter information of the device may be of an application scenario type.
  • the parameter information may also be parameters related to the processing capability of the device, such as the number of CPUs, the size of memory, and the like.
  • the configuration suggestions for functional components given in combination with the processing capability of the device mainly consider the resource consumption of the device by different configuration positions of the functional components. Simply put, if the device processing capability is weaker, it may be recommended to configure more functional components into the kernel. On the contrary, if the device processing capability is weaker, it may be recommended to configure more functional components into the user space.
  • the parameter value cases of various device processing capabilities can be preset, and the configuration suggestions of the functional components in each value case can be counted or tested for the user's reference.
  • the user can refer to the corresponding configuration suggestion according to the processing capability of the device to be set.
  • the process that the user completes the configuration of the functional components in the operating system based on the configuration suggestion corresponding to the device parameter information may be performed with reference to the embodiment shown in FIG. 5b.
  • a configuration suggestion corresponding to the application scenario type is given on the configuration interface.
  • the application scenario type input by the user is a vehicle terminal, and the corresponding configuration suggestions are: functional component M1 and functional component M3 are configured in user process U1, functional component M2 is configured in user process U2, functional component M4 and functional component M5 configured in the kernel.
  • the user can decide to adopt the configuration suggestion, or modify the configuration suggestion.
  • select all the configuration suggestions and directly click the "OK" button in the configuration interface to trigger the configuration request corresponding to the configuration suggestion.
  • the user wants to modify some of the configuration suggestions a corresponding modification operation is performed, and then an "OK" operation is triggered for the modification result to trigger a configuration request corresponding to the modified configuration suggestion. Then, based on the configuration process described in the foregoing embodiment, the configuration process is completed in response to the configuration request.
  • FIG. 6 is a flowchart of a method for invoking a functional component provided by an embodiment of the present invention. As shown in FIG. 6 , the invoking method includes the following steps:
  • the target functional component in the operating system has been configured to the target configuration location.
  • the target configuration location may be the kernel or a user process in the user space.
  • calls to functional components in the operating system are generally initiated by a user program running in user space (ie, a user program in user mode).
  • the operating system can also be divided into user space and kernel, and the user process running in the user space in the operating system is also in the user state.
  • the above-mentioned second user process is also a user process running in the user mode, but the second user process may be a user process in a user space outside the operating system.
  • a user program is running in the second user process. In this embodiment, it is assumed that the user program initiates a call to the target functional component.
  • the file path of the target functional component will be carried in the invocation request for calling the target functional component. Since the file path corresponding to the target functional component will be registered during the registration process of the target functional component to the target configuration location, the file path corresponding to the target functional component can be registered in the operating system Query the registration information containing the file path to determine the target configuration location of the target functional component.
  • the query in the operating system refers to the query in the user space of the operating system, specifically, the query in the virtual file system in each user process, and the query in the path management module in the user space.
  • the reason why the query is made in the user space and not the kernel is because the user program works in the user mode and does not have the right to directly query the kernel.
  • the query result indicates that the target functional component is not queried in the user space of the operating system, it means that the target functional component is in the kernel.
  • the user program may be notified to call the target functional component in a calling manner corresponding to the target configuration location.
  • the first situation the user program and the target functional component are in the same user process, at this time, the user program will use the function call method to call the target functional component;
  • the second situation the user program and the target functional component are in different user processes in the user mode. At this time, the user program will use the RPC method to call the target functional component;
  • the third situation the target functional component is in the kernel, at this time, the user program will use the system call (system call) method to call the target functional component.
  • system call system call
  • the target functional component has been configured into the second user process in the configuration phase, that is, it is located in the same user process as the user program.
  • the second user process includes a third virtual file system
  • the third virtual file system will contain the file path and callback function related information corresponding to the target functional component.
  • the module will contain the file path and remote procedure call identifier (ie RPC_ID) corresponding to the target functional component.
  • the virtual file system in the user process where the user program is located can be queried first, and then the path management module can be queried.
  • the third The file path of the target functional component is queried in the virtual file system, thereby determining that the target configuration location of the target functional component is the second user process.
  • the relevant information of the callback function corresponding to the file path stored in the third virtual file system is obtained, and the relevant information of the callback function is sent to the user program, so that the user program can use the function call according to the relevant information of the callback function. way to call the target functional component.
  • the target functional component has been configured into the first user process in the configuration phase, that is, it is not located in the same user process as the user program.
  • the first user process includes the first virtual file system
  • the first virtual file system will include the file path corresponding to the target functional component and the relevant information of the callback function.
  • the path management The module will contain the file path and remote procedure call identifier (ie RPC_ID) corresponding to the target functional component.
  • the user program After the user program triggers the calling request containing the file path of the target functional component, according to the order of first querying the virtual file system in the user process where the user program is located, and then querying the path management module, first, the third virtual file system in the second user process is queried.
  • the file path of the target functional component is not queried in the file system, but the file path of the target functional component is queried in the path management module in the user space, then it is determined that the target configuration location of the target functional component is different from the second user process. other user processes.
  • the remote procedure call identifier corresponding to the file path stored in the path management module is obtained, and the remote procedure call identifier is sent to the user program, so that the user program can call the target function in a remote procedure call manner according to the remote procedure call identifier components.
  • the remote procedure call identifier corresponding to the file path stored in the path management module is obtained, and the remote procedure call identifier is sent to the user program, so that the user program can call the target function in a remote procedure call manner according to the remote procedure call identifier components.
  • the path management module finds that the file path of the target functional component is not queried in the path management module, it is directly determined that the target configuration location of the target functional component is not user process, but the kernel.
  • the user program is notified to call the target functional component by means of a system call.
  • the target functional component in simple terms: the user program makes itself fall into the kernel state from the user state through the preset system call instruction, and then queries the second virtual file system in the kernel state with the target functional component. The relevant information of the corresponding callback function, and the target functional component is called based on the relevant information of the callback function.
  • the system call method involves frequent transitions between user mode and kernel mode, so the operating efficiency is low.
  • the remote procedure call method is an inter-process communication method. Compared with the function call method in the user process, it also consumes more resources and has lower operating efficiency.
  • the user can decide the configuration location of the functional component as needed, can configure the functional component in the user state (user space) or the kernel state (kernel), and can further configure different functional components In the same user process of the user mode, in order to improve the operating efficiency.
  • the calling process provided by the embodiment of FIG. 6 is inherited from the configuration scheme of the functional components in the embodiment shown in FIG. 4a.
  • the call request includes the file path corresponding to the target functional component, and the user program is located in the first user process in the user space;
  • the target configuration location is any one of the following: the kernel, the first user process, and the second user process in the user space;
  • FIG. 8 is a schematic structural diagram of a functional component processing apparatus according to an embodiment of the present invention. As shown in FIG. 8 , the functional component processing apparatus includes: a receiving module 11 and a configuration module 12 .
  • the receiving module 11 is configured to obtain a configuration request, where the configuration request includes an identifier of a target functional component in an operating system and a target configuration location of the target functional component in the operating system.
  • the configuration module 12 is configured to configure the target functional component to the target configuration location, where the target configuration location is located in the user space or the kernel; generate the target functional component in the virtual file system corresponding to the target configuration location registration message.
  • the apparatus further includes: an obtaining module, configured to obtain parameter information of a device on which the operating system is installed; and output a configuration suggestion corresponding to the parameter information, where the configuration suggestion indicates a configuration suggestion included in the operating system.
  • an obtaining module configured to obtain parameter information of a device on which the operating system is installed; and output a configuration suggestion corresponding to the parameter information, where the configuration suggestion indicates a configuration suggestion included in the operating system.
  • Recommended configuration locations corresponding to multiple functional components.
  • the parameter information includes application scenario type and/or device processing capability.
  • the target configuration location is the first user process in the user space
  • the configuration module 12 is specifically configured to: write the target function component corresponding to the first virtual file system in the first user process. information about the file path and the callback function; and writing the file path and the remote procedure call identifier corresponding to the target functional component in the path management module in the user space.
  • multiple functional components are configured in the first user process, and the multiple functional components include the target functional component.
  • the multiple functional components have a collocation relationship.
  • the target configuration location is the kernel
  • the configuration module 12 is specifically configured to: write the file path corresponding to the target functional component and the related information of the callback function in the second virtual file system in the kernel.
  • the apparatus further includes: a calling module, configured to receive, through the receiving module 11, a calling request triggered by a user program in the second user process, where the calling request includes a file path corresponding to the target functional component ; According to the file path corresponding to the target functional component, determine the target configuration position of the target functional component, and the registration information includes the file path; notify the user program with the calling mode corresponding to the target configuration position Invoke the target functional component.
  • a calling module configured to receive, through the receiving module 11, a calling request triggered by a user program in the second user process, where the calling request includes a file path corresponding to the target functional component ; According to the file path corresponding to the target functional component, determine the target configuration position of the target functional component, and the registration information includes the file path; notify the user program with the calling mode corresponding to the target configuration position Invoke the target functional component.
  • the calling module is specifically configured to: if the file path is queried in the third virtual file system in the second user process, determine that the target configuration location of the target functional component is the first Two user processes; obtain the relevant information of the callback function corresponding to the file path stored in the third virtual file system, where the registration information stored in the third virtual file system includes the file path corresponding to the target functional component and the relevant information of the callback function; send the relevant information of the callback function to the user program, so that the user program can call the target function component in a function call manner according to the relevant information of the callback function.
  • the calling module is specifically configured to: if the file path is queried in the path management module in the user space, determine that the target configuration location of the target functional component is another user process; obtain the the remote procedure call identifier corresponding to the file path stored in the path management module, and the registration information stored in the path management module includes the file path and the remote procedure call identifier corresponding to the target functional component; sending the identifier to the user program
  • the remote procedure call identifier enables the user program to call the target functional component in a remote procedure call manner according to the remote procedure call identifier.
  • the calling module is specifically configured to: if the file path is not queried in the path management module in the user space, determine that the target configuration location of the target functional component is the kernel; notify the user The program invokes the target functional component in the form of a system call.
  • the functional component processing apparatus shown in FIG. 8 may execute the method provided in the foregoing embodiment.
  • the functional component processing apparatus shown in FIG. 8 may execute the method provided in the foregoing embodiment.
  • the structure of the functional component processing apparatus shown in FIG. 8 can be implemented as an electronic device.
  • the electronic device may include: a processor 21 , a memory 22 , and an operating system 23 .
  • the memory 22 stores executable codes, and when the executable codes are executed by the processor 21, at least the processor 21 can realize the processing of the functional components provided in the foregoing embodiments.
  • the structure of the electronic device may also include interfaces such as I/O interfaces, communication interfaces and the like.
  • an embodiment of the present invention provides a non-transitory machine-readable storage medium, where executable codes are stored on the non-transitory machine-readable storage medium, and when the executable codes are executed by a processor of an electronic device , causing the processor to execute the processing of the functional components provided in the foregoing embodiments.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

本发明实施例提供一种功能组件处理方法、介质、设备和操作系统，操作系统包括内核和用户空间，内核以及用户空间的各用户进程中均配置有虚拟文件系统。该方法包括：获取配置请求，配置请求中包括操作系统中目标功能组件的标识以及目标功能组件在操作系统中的目标配置位置；将目标功能组件配置到目标配置位置，目标配置位置位于用户空间的用户进程或内核；在目标配置位置对应的虚拟文件系统中生成目标功能组件的注册信息，以完成操作系统中功能组件的按需灵活配置。

Description

功能组件处理方法、介质、设备和操作系统
本申请要求2021年04月21日递交的申请号为202110432412.2、发明名称为“功能组件处理方法、介质、设备和操作系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明涉及计算机技术领域，尤其涉及一种功能组件处理方法、介质、设备和操作系统。
背景技术
操作系统中会包含操作系统内核，从操作系统内核的架构来划分，操作系统内核可分为微内核(Micro Kernel)和宏内核(Monolithic Kernel)。
图1和图2分别示意了宏内核和微内核的一种典型结构。如图1所示，在宏内核中，操作系统中的诸如进程管理、存储器管理、设备管理、文件系统、网络协议、时钟管理、中断处理、原语(如CPU切换、设备驱动等)等功能组件都设置在操作系统内核中。但是，如图2所示，在微内核中，操作系统中的诸如进程管理、存储器管理、设备管理、文件系统、网络协议等功能组件被设置在操作系统内核外的用户态(用户空间)中，而一些核心操作所涉及到的诸如时钟管理、中断处理、原语等功能组件设置在操作系统内核中。
在目前上述固定配置的宏内核和微内核的架构中，虽然上述微内核架构简化了操作系统内核的组成，但是很多时候微内核的运行效率却不高；虽然上述宏内核架构有利于保证内核的运行效率，但是操作系统内核复杂，对使用的设备的门槛较高。这两种内核架构的普适性较差，用户粘性差。
发明内容
本发明实施例提供一种功能组件处理方法、介质、设备和操作系统，用以实现用户对操作系统的灵活配置。
第一方面，本发明实施例提供一种功能组件处理方法，操作系统包括内核和用户空间，所述内核以及所述用户空间的各用户进程中均配置有虚拟文件系统，该方法包括：
接收用户的配置请求，所述配置请求中包括操作系统中目标功能组件的标识以及所述目标功能组件在所述操作系统中的目标配置位置；
将所述目标功能组件配置到所述目标配置位置，所述目标配置位置位于用户空间或内核；
在所述目标配置位置对应的虚拟文件系统中生成所述目标功能组件的注册信息。
第二方面，本发明实施例提供一种功能组件处理装置，操作系统包括内核和用户空间，所述内核以及所述用户空间的各用户进程中均配置有虚拟文件系统，该装置包括：
接收模块，用于获取配置请求，所述配置请求中包括操作系统中目标功能组件的标 识以及所述目标功能组件在所述操作系统中的目标配置位置；
配置模块，用于将所述目标功能组件配置到所述目标配置位置，所述目标配置位置位于用户空间或内核；在所述目标配置位置对应的虚拟文件系统中生成所述目标功能组件的注册信息。
第三方面，本发明实施例提供一种功能组件处理方法，操作系统包括内核和用户空间，所述内核以及所述用户空间的各用户进程中均配置有虚拟文件系统；所述方法包括：
确定位于所述操作系统中第一配置位置的目标功能组件；
将所述目标功能组件配置到第二配置位置，所述第一配置位置和所述第二配置位置分别位于所述用户空间的用户进程或所述内核，所述第一配置位置和所述第二配置位置不同；
在所述第二配置位置对应的虚拟文件系统中生成所述目标功能组件的注册信息。
第四方面，本发明实施例提供一种功能组件处理方法，操作系统包括内核和用户空间，所述方法包括：
接收用户程序触发的调用请求，所述调用请求中包括目标功能组件对应的文件路径，所述用户程序位于所述用户空间中的第一用户进程；
根据所述目标功能组件对应的文件路径，确定所述目标功能组件的目标配置位置，所述目标配置位置为如下任一种：所述内核，所述第一用户进程，所述用户空间中的第二用户进程；
通知所述用户程序以与所述目标配置位置对应的调用方式调用所述目标功能组件。
第五方面，本发明实施例提供一种电子设备，包括处理器、存储器、操作系统，其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器至少可以实现第一方面或第三方面或第五方面中的功能组件处理方法。
第六方面，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器至少可以实现第一方面或第三方面或第五方面中的功能组件处理方法。
第七方面，本发明实施例提供一种操作系统，包括：
内核和用户空间；
所述用户空间的各用户进程中均配置有虚拟文件系统；所述用户空间中配置有路径管理模块；
所述内核中配置有虚拟文件系统；
所述用户空间的目标用户进程中包含用户配置的至少一个第一功能组件，所述目标用户进程中的虚拟文件系统中包含所述至少一个第一功能组件的第一注册信息；
所述路径管理模块中包含所述用户空间内的各用户进程中所配置的功能组件的第二注册信息；
所述内核中包含用户配置的至少一个第二功能组件，所述内核中的虚拟文件系统中包含所述至少一个第二功能组件的注册信息。
在本发明实施例中，在操作系统的内核和用户空间的各用户进程中都设置有虚拟文件系统(Virtual File System，简称VFS)，以用于支持用户对操作系统中各功能组件的按需灵活配置。有别于传统的操作系统内核的固定配置方案，基于本发明实施例中提供的方案，用户可以针对操作系统中包含的功能组件按需配置其所处位置是在操作系统的内核中还是在用户空间的某用户进程中。具体地，在接收到用户触发的包括目标功能组件的标识以及目标功能组件的目标配置位置的配置请求时，一方面将目标功能组件配置到该目标配置位置，目标配置位置位于用户空间的用户进程或内核，另一方面在目标配置位置对应的VFS中生成目标功能组件的注册信息，这样就完成了功能组件的配置。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为传统的一种宏内核的结构示意图；
图2为传统的一种微内核的结构示意图；
图3a为本发明一实施例提供的操作系统架构的示意图；
图3b为本发明一实施例提供的操作系统配置和调用场景的示意图；
图4a为本发明一实施例提供的功能组件处理方法的流程图；
图4b为与图4a所示功能组件处理方法对应的配置界面的示意图；
图5a为本发明另一实施例提供的功能组件处理方法的流程图；
图5b为与图5a所示功能组件处理方法对应的配置界面的示意图；
图6为本发明一实施例提供的功能组件调用方法的流程图；
图7a为本发明一实施例提供的功能组件调用场景的示意图；
图7b为本发明另一实施例提供的功能组件调用场景的示意图；
图7c为本发明另一实施例提供的功能组件调用场景的示意图；
图8为本发明一实施例提供的功能组件处理装置的结构示意图；
图9为本发明一实施例提供的电子设备的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明实施例提供的功能组件处理方法可以使得用户能够按需灵活对设备中的操作 系统进行配置，或者说对操作系统的内核进行配置。具体地，是可以配置操作系统中包含的功能组件的配置位置。操作系统的体系架构分为内核态和用户态，或者说内核和用户空间，因此，上述配置位置分为两类：内核和用户空间。其中，在用户空间，具体是配置在用户空间的用户进程中。
本发明实施例提供的方案可以视为是对传统的固定配置的微内核和宏内核架构的优化。本文中的功能组件是指操作系统中提供某种功能的模块。
如果将操作系统中包含的功能组件划分为基础组件(或核心组件)和非基础组件(或非核心组件)，比如时钟管理、中断处理、原语等功能组件作为基础组件，诸如进程管理、存储器管理、设备管理、文件系统、网络协议等功能组件作为非基础组件，那么，可以认为在传统的宏内核架构下，基础组件和非基础组件都被固定地配置在内核中，处于内核态；在传统的微内核架构下，基础组件被固定地配置在内核中，处于内核态，而非基础组件被固定地配置在用户空间中，处于用户态。
而在本发明实施例提供的方案中，可以仍将基础组件配置在内核中，而用户可以按需对非基础组件进行灵活配置，比如，可以将一些非基础组件配置在用户空间，可以将另一些非基础组件配置在内核，还可以将某非基础组件的一部分功能配置在内核而将另一部分功能配置在用户空间。当然，用户也可以按需对基础组件的配置位置进行灵活设置。
不管用户按需将操作系统中的某功能组件配置在哪里(内核或用户空间的某用户进程)，都需要支持在某用户程序需要调用该功能组件的时候，能够调用到该功能组件，为能够实现对该功能组件的调用，在功能组件配置的时候需要进行相应的配置处理，而该配置处理的过程会改变传统的操作系统的架构，也会改变功能组件的调用方式。下面结合图3a来示例性说明本发明实施例提供的一种操作系统的架构。
图3a为本发明一实施例提供的操作系统架构的示意图，如图3a所示，该操作系统中包括：内核和用户空间。其中，在用户空间的各用户进程中均配置有虚拟文件系统，在内核中也配置有虚拟文件系统。实际应用中，不同虚拟文件系统中所包含的信息是不同的。另外，用户空间中配置有路径管理(Path Manager)模块，用于对用户空间的所有用户进程中包含的功能组件进行注册信息的统一管理。
也就是说，内核中配置有一个虚拟文件系统，处于内核态；在用户空间的每个用户进程中都配置有处于用户态的虚拟文件系统。
比如，在图3a中，假设将内核中设置的虚拟文件系统表示为：Kernel_VFS。在图3a中，假设用户空间存在用户进程A、用户进程B和用户进程C，用户进程A中包含的虚拟文件系统表示为：A0S_VFSa,用户进程B中包含的虚拟文件系统表示为：A0S_VFSb,用户进程C中包含的虚拟文件系统表示为：A0S_VFSc。
如图3a中所示，实际上，每个用户进程中都会包含有一个标准的函数库，比如图中 示意的LIBC，在这个函数库中设有虚拟文件系统。因此，不同用户进程通过加载包含有虚拟文件系统的这个函数库，便可以实现本地的虚拟文件系统的设置。之后，基于用户对功能组件的配置操作，向相应配置位置处的虚拟文件系统中写入对应的注册信息即可。
在图3a中，假设路径管理模块被设置在用户进程C中，实际上，不以此为限，该路径管理模块也可以运行在其他用户进程中，比如管理进程中。
对比来说，一个用户进程中的虚拟文件系统中仅存储有注册到该用户进程的功能组件的注册信息，而路径管理模块中存储的是注册到各个用户进程的功能组件的注册信息，即全部的注册到用户态的功能组件的注册信息。并且，针对同一功能组件来说，其在某用户进程的虚拟文件系统中对应的注册信息与在路径管理模块中对应的注册信息是不同的。
上文中所说不同虚拟文件系统中包含的信息不同，可以认为即是不同虚拟文件系统中包含的功能组件的注册信息不同。
如上文所述，用户可以按需灵活地配置操作系统中各功能组件的配置位置。假设用户将至少一个第一功能组件的配置位置设为用户空间的某个用户进程(称为目标用户进程)，那么从配置结果来说，用户空间的目标用户进程中会包含用户配置的该至少一个第一功能组件，而且，目标用户进程中的虚拟文件系统中会包含该至少一个第一功能组件的第一注册信息。此时，还需将该至少一个第一功能组件的第二注册信息写入路径管理模块中。第一注册信息和第二注册信息不同，该不同点主要体现为两个注册信息中包含的第一功能组件的调用信息不同，即对应于两种不同的调用方式。总结来说，一个功能模块的注册信息中会包含与该功能模块对应的调用信息，功能模块的配置位置不同，那么其对应的调用信息亦会不同。具体注册信息的组成将在后续实施例中具体说明。
假设用户将至少一个第二功能组件的配置位置设为内核，那么从配置结果来说，内核中会包含用户配置的该至少一个第二功能组件，而且，内核中的虚拟文件系统中会包含该至少一个第二功能组件的注册信息。
在图3a中示例的是用户将设备驱动1和闪存(Flash)这两个功能组件配置到同一用户进程A中，将网络协议和网卡这两个功能组件配置到同一用户进程B中，将文件系统(File System)这个功能组件配置到用户进程C中。另外，用户将设备驱动2这个功能组件配置到内核中。其中，设备驱动1和设备驱动2是指分别提供部分设备驱动功能的功能组件，可以认为将传统的设备驱动功能划分为两个功能组件来提供。另外，在图3a中，假设诸如时钟管理、中断处理等基础的功能组件配置在内核中。
由上述举例可知，用户进程A中的虚拟文件系统A0S_VFSa中会包含设备驱动1和闪存这两个功能组件的注册信息，用户进程B中的虚拟文件系统A0S_VFSb中会包含网络协议和网卡这两个功能组件的注册信息，用户进程C中的虚拟文件系统A0S_VFSc中会包含文件系统这个功能组件的注册信息，内核中的虚拟文件系统Kernel_VFS中会包含 设备驱动2、时钟管理、中断处理等这些功能组件的注册信息。
由上述举例可知，从配置效果角度来说，基于本发明实施例提供的配置方案，最终可以实现操作系统中功能组件的“可上可下”和“可合并”。
其中，可上可下是指：功能组件可以被配置为运行在内核态或者用户态，而不再受限于传统宏内核和微内核架构下的固定设置结果。比如，假设某功能组件在传统微内核架构下只能运行在用户态，基于本发明实施例提供的方案，该功能组件可以被配置为运行在内核态。
其中，可合并是指：不同功能组件可以被配置为运行在用户空间的同一用户进程中，当然，不同功能组件也可以运行在用户空间的不同用户进程中。不再受限于传统微内核架构下的不同功能组件只能运行在不同用户进程中的固定设置结果。当几个功能组件运行在同一用户进程中时，可以提高操作系统的运行效率，因为同一用户进程中不同功能组件间的调用方式可以被优化为采用函数调用的方式，而不必受限于传统的不同功能组件间的调用方式只能采用远程过程调用(Remote Procedure Call，简称RPC)方式。
为先有一种直观而笼统的印象，下面结合图3b来示例性说明操作系统中功能组件的配置和调用过程。
由于本发明实施例提供的方案可以认为是对传统的操作系统架构的优化，因此，为便于理解，如图3b所示，假设如下情形：假设在传统的宏内核架构中，功能组件W1、功能组件W2、功能组件W3和功能组件W4都位于内核中，并假设用户空间中包括用户进程1和用户进程2这两个用户进程。在该宏内核架构下，比如用户进程2中的某用户程序想要调用内核中的上述四个功能组件中的任一个，则需要通过系统调用的方式来调用。
如图3b中所示，基于本发明实施例提供的方案，用户可以按需对宏内核进行如下优化配置：将功能组件W2配置到用户进程1中，将功能组件W3配置到用户进程2中，功能组件W1和功能组件W4仍旧位于内核中。基于该配置结果，这四个功能组件的调用方式将会发生改变。简单来说：如果用户进程2中的某用户程序想要调用内核中的上述功能组件W1或功能组件W4，则需要通过系统调用的方式来调用；如果用户进程2中的某用户程序想要调用上述功能组件W2，则需要通过RPC的方式来调用；如果用户进程2中的某用户程序想要调用功能组件W3，则需要通过函数调用的方式来调用。
以上从宏观角度对操作系统的架构和功能组件的配置及调用过程进行了概括说明，下面结合以下一些实施例详细说明功能组件的配置及调用过程。
以下方法实施例可以由电子设备中的处理器来执行，该电子设备中设有操作系统，操作系统包括上文中提到的用户空间和内核。基于以下实施例提供的方案，用户可以实现对操作系统中功能组件的灵活配置。该电子设备可以是诸如嵌入式设备、数字助手、机器人等终端设备，不以此为限。
图4a为本发明一实施例提供的功能组件处理方法的流程图，如图4a所示，该方法可以包括如下步骤：
401、获取配置请求，配置请求中包括操作系统中目标功能组件的标识以及目标功能组件在操作系统中的目标配置位置，目标配置位置位于用户空间的用户进程或内核。
402、将目标功能组件配置到目标配置位置。
403、在目标配置位置对应的虚拟文件系统中生成目标功能组件的注册信息。
假设用户在开发或使用某用户设备的过程中，想要对该用户设备中的操作系统进行按需配置，即配置操作系统中各功能组件运行在哪里，此时，用户可以触发上述配置请求。其中，上述目标功能组件是操作系统中的任一功能组件。
用户可以对操作系统中包含的各个功能组件进行运行位置的配置，在针对目标功能组件进行配置时，配置请求中携带目标功能组件的标识以及目标配置位置，目标配置位置即为希望目标功能组件被配置到的位置，是内核或用户空间中的某用户进程。
实际应用中，为便于用户的配置操作，可以为用户提供相应的配置界面，以便用户通过该配置界面触发配置操作。
下面结合图4b示例性说明一种配置界面。
如图4b所示，在该配置界面中可以包括操作系统中包含的各功能组件的标识，比如图中示意的时钟管理、中断管理、设备驱动、文件系统、网络协议等功能组件的标识。另外，配置界面中还设有多个配置位置的选项，其中，主要包括两类选项：第一种选项是内核，第二种选项是用户空间中的用户进程。
其中，假设用户空间中的用户进程包括图4b中示意的用户进程A、用户进程B和用户进程C，那么第二种选项具体可以是：这三个用户进程。即可以在配置项中呈现出所有可以选择的配置位置。用户针对每个功能组件，可以按需选择对应的配置位置即可，配置结果如图4b中所示。
实际应用中，用户可以在编译操作系统的过程中触发上述配置过程。假设用户针对目标功能组件设置了目标配置位置，则一方面需要将目标功能组件的代码编译到目标配置位置，并启动目标功能组件，进行组件初始化。比如，假设目标配置位置为内核，则需要将目标功能组件编译到内核代码中，在内核代码中启动目标功能组件，进行组件初始化。另一方面，还需要完成目标功能组件的注册处理，即将目标功能组件注册到目标配置位置对应的虚拟文件系统中。其中，在目标配置位置对应的虚拟文件系统中生成的目标功能组件的注册信息，在调用目标功能组件的过程中将被使用到。
下面针对目标功能组件的目标配置位置的不同，分别说明在将目标功能组件配置到不同配置位置时需要注册的信息有何不同。
第一种情形：假设目标配置位置为用户空间中的第一用户进程，此时，需要在第一用户进程中的第一虚拟文件系统中写入目标功能组件对应的文件路径和回调函数的相关 信息。其中，第一虚拟文件系统是指位于第一用户进程中的虚拟文件系统，也就是说，需要将目标功能组件的文件路径和回调函数相关信息注册到第一虚拟文件系统中。其中，文件路径是指目标功能组件对应的存储路径或者说引用路径，在将目标功能组件配置到目标配置位置时可以自动得到；回调函数的相关信息中可以包括回调函数指针以及函数参数等信息，这里主要使用到的是回调函数指针。
当目标功能组件的目标配置位置位于用户空间时，除了需要将目标功能组件注册到上述第一虚拟文件系统外，还需要将目标功能组件注册到用户空间的路径管理模块中。具体地，需要在用户空间中的路径管理模块中写入目标功能组件对应的文件路径和RPC_ID，即远程过程调用标识。
这揭示出注册到用户态(即用户空间的用户进程)的功能组件的调用方式可以有两种：一种是函数调用方式，另一种是RPC方式。调用过程将在后续其他实施例中详细说明。
上述以目标功能组件这一个组件为例说明了其在用户空间的第一用户进程中的注册过程。实际上，用户还可能将其他功能组件也配置到第一用户进程，那么基于上述注册过程，第一用户进程中会最终配置有多个功能组件，相应地，第一用户进程中的第一虚拟文件系统中也将会包含这多个功能组件各自的文件路径和回调函数的相关信息，路径管理模块中也会包含这多个功能组件各自的文件路径和RPC_ID。
在实际应用中，用户可以将具有搭配使用关系的多个功能组件配置到用户空间的同一用户进程中。这样可以在这多个功能组件彼此之间需要调用的时候，采用函数调用方式实现，提高效率。
第二种情形：假设目标配置位置为内核，此时，需要在内核中的第二虚拟文件系统(即Kernel_VFS)中写入目标功能组件对应的文件路径和回调函数的相关信息。其中，如上文所述，回调函数的相关信息可以包括回调函数指针和函数参数。
在上述实施例提供的功能组件处理方案中，用户可以根据自身经验来设定不同功能组件的配置位置。实际应用中，为提高用户配置过程的便利性，降低用户配置操作的难度，还可以提供给用户一些配置建议，以便用户参考该配置建议来完成功能组件的配置。
如前文所述，本发明实施例提供的功能组件配置方案会改变操作系统的架构，即相当于是对传统的宏内核或微内核架构的操作系统进行了优化，该优化主要体现为操作系统中功能组件的配置位置的改变，因此，在操作系统的内核以及用户空间的各用户进程中均配置了虚拟文件系统的基础上，功能组件的配置过程还可以描述为：
确定位于操作系统中第一配置位置的目标功能组件；
将目标功能组件配置到第二配置位置，第一配置位置和第二配置位置分别位于用户空间的用户进程或内核，第一配置位置和第二配置位置不同；
在第二配置位置对应的虚拟文件系统中生成目标功能组件的注册信息。
其中，目标功能组件是操作系统中包含的任一功能组件。
其中，第一配置位置和第二配置位置分别位于用户空间的用户进程或内核，第一配置位置和第二配置位置不同，是指：如果第一配置位置位于用户空间的某用户进程中，则第二配置位置位于内核中；如果第一配置位置位于内核中，则第二配置位置位于用户空间的某用户进程中。
上述配置过程对操作系统架构的优化主要体现为：第一，在内核以及各用户进程中都设有VFS，以写入本地功能组件的相关注册信息，为后续调用功能组件提供前提；第二，将原本位于第一配置位置的目标功能组件切换配置到第二配置位置处，即实现功能组件由内核态切换为用户态，或者由用户态切换为内核态。
需要说明的是，如果将某个功能组件进行更细粒度的划分，比如按照功能拆分为多个子组件，那么按照上述配置方案，可以将其中的部分子组件配置在用户态，而将剩余的部分子组件配置在内核态。
以上介绍的是用户可以按需自主决定各个功能组件的配置位置，下面提供另一种可选的功能组件的配置方案。
图5a为本发明另一实施例提供的功能组件处理方法的流程图，如图5a所示，该方法可以包括如下步骤：
501、获取安装操作系统的设备的参数信息，输出与参数信息对应的配置建议，该配置建议指示操作系统中包含的多个功能组件各自对应的推荐配置位置。
502、接收用户的配置请求，配置请求中包括操作系统中目标功能组件的标识以及目标功能组件在操作系统中的目标配置位置，目标配置位置位于用户空间的用户进程或内核。
503、将目标功能组件配置到目标配置位置。
504、在目标配置位置对应的虚拟文件系统中生成目标功能组件的注册信息。
本实施例中，在需要对安装有某操作系统的设备进行操作系统中功能组件的配置时，可以结合该设备的一些参数信息给出配置建议，以供用户参考。
假设针对目标功能组件，该配置建议中给出该目标功能组件的推荐配置位置为内核，那么上述配置请求中该目标功能组件的目标配置位置可以是用户采纳了配置建议而确定的该推荐配置位置，也可以是用户未采纳了该配置建议而确定的另一配置位置。
本实施例中，可选地，设备的参数信息可以包括但不限于：应用场景类型、设备处理能力等信息中的一种或多种。
其中，应用场景类型可以是：安装上述操作系统的设备的使用场景。比如，该设备可能是被应用到人机对话场景中的智能机器人，该设备也可能是被应用到生产车间中的检测设备，该设备还可能是被应用到车辆中的车载终端。
不同应用场景中的设备所需要完成的主要任务是不同的。比如在人机对话场景中的 智能机器人的主要任务就是完成与用户的智能问答；在生产车间场景中的检测设备的主要任务是对生产环境中的一些指标进行检测；车载终端的主要任务是提供导航相关服务。而不同任务对操作系统中不同功能组件的使用频率也可能是不同的。
基于此，可以通过统计得到不同应用场景对应的配置建议。
举例来说，假设安装有某操作系统的设备是应用在人机对话场景中的智能机器人，那么给出的配置建议如下：
功能组件M1、功能组件M2和功能组件M3配置在用户进程U1中，功能组件M4配置在用户进程U2中，功能组件M5配置在内核中。
再假设安装有上述操作系统的设备是车载终端，那么给出的配置建议如下：
功能组件M1和功能组件M3配置在用户进程U1中，功能组件M2配置在用户进程U2中，功能组件M4和功能组件M5配置在内核中。
其中，在给出不同功能组件的配置建议时，通过预先对不同应用场景中功能组件的搭配使用关系的统计分析，可以给出将多个功能组件配置在同一目标配置位置的建议，比如在上述车载终端场景中给出将搭配使用的功能组件M1和功能组件M3配置在用户进程U1中的建议，在上述智能机器人的应用场景中给出将搭配使用的功能组件M1、功能组件M2和功能组件M3配置在用户进程U1中的建议。
上述举例说明了设备的参数信息可以是应用场景类型的情形。实际应用中，该参数信息还可以是设备处理能力相关的参数，比如CPU个数、内存大小等等。结合设备处理能力给出功能组件的配置建议主要是考虑了功能组件的不同配置位置对设备的资源消耗情况。简单来说，如果设备处理能力越弱，则可以建议将多一些的功能组件配置到内核中，相反地，如果设备处理能力越弱，则可以建议将多一些的功能组件配置到用户空间中。
可选地，可以预先设定多种设备处理能力的参数取值情形，统计或测试出每种取值情形功能组件的配置建议，以供用户参考。用户可以根据需要被设置的设备的处理能力查询对应的配置建议来参考。
用户基于设备参数信息所对应的配置建议来完成操作系统中功能组件的配置的过程，可以参考图5b所示实施例来执行。
在图5b中，假设设备参数为设备的应用场景类型，用户首先输入设备的应用场景类型，此时，在配置界面上会给出与该应用场景类型对应的配置建议。假设用户输入的应用场景类型为车载终端，并假设对应的配置建议为：功能组件M1和功能组件M3配置在用户进程U1中，功能组件M2配置在用户进程U2中，功能组件M4和功能组件M5配置在内核中。
用户可以确定采用该配置建议，或者对该配置建议进行修改。当用户采用该配置建议时，选中全部的配置建议，直接点击配置界面中的“确定”按钮，触发与该配置建议 对应的配置请求。当用户想要对其中的部分配置建议进行修改时，执行对应的修改操作，之后，针对修改结果触发“确定”操作，以触发与修改后的配置建议对应的配置请求。之后基于前述实施例介绍的配置过程，响应配置请求，完成配置过程。
在图5b中，假设用户对其中的部分配置建议进行了修改，将功能组件M4配置到了用户进程U2中。
前述实施例介绍了操作系统中功能组件的配置过程。下面结合以下实施例介绍基于上述配置结果的功能组件调用过程。
图6为本发明一实施例提供的功能组件调用方法的流程图，如图6所示，该调用方法包括如下步骤：
601、接收第二用户进程中的用户程序触发的调用请求，调用请求中包括目标功能组件对应的文件路径。
602、根据目标功能组件对应的文件路径，确定目标功能组件的目标配置位置，目标功能组件的注册信息中包括该文件路径。
603、通知用户程序以与目标配置位置对应的调用方式调用目标功能组件。
本实施例中假设操作系统中的目标功能组件已经被配置到目标配置位置，如前文所述，该目标配置位置可以是内核，或者是用户空间中的用户进程。
实际应用中，对操作系统中的功能组件进行调用，一般是由用户空间运行的用户程序(即用户态的用户程序)发起的。需要说明的是，操作系统内也可以划分为用户空间和内核，运行在操作系统内的用户空间中的用户进程也是处于用户态的。本实施例中，上述第二用户进程也是运行在用户态的用户进程，只是该第二用户进程可以是操作系统外的用户空间中的用户进程。在该第二用户进程中运行着一个用户程序。本实施例中假设该用户程序发起了对目标功能组件的调用。
在调用目标功能组件的调用请求中会携带有目标功能组件的文件路径，由于在目标功能组件向目标配置位置的注册过程中都会注册有目标功能组件对应的文件路径，因此，可以通过在操作系统中查询包含该文件路径的注册信息以确定目标功能组件的目标配置位置。
其中，在操作系统中查询，是指在操作系统的用户空间中查询，具体是在其中的各用户进程中的虚拟文件系统中进行查询，以及在该用户空间中的路径管理模块中查询。之所以在用户空间中查询，而不查询内核，是因为用户程序是工作在用户态的，不具有直接查询内核的权限。但是，可以理解的是，如果查询结果表明在操作系统的用户空间内没有查询到目标功能组件，那么则说明目标功能组件在内核中。
上文中提到，目标功能组件的不同配置位置，将会导致目标功能组件的调用方式的不同。因此，在确定目标功能组件的目标配置位置后，可以通知用户程序以与该目标配置位置对应的调用方式调用目标功能组件。
概括来说，实际应用中，会遇到三种目标功能组件的调用情形，分别是：
第一种情形：用户程序与目标功能组件在同一用户进程中，此时，用户程序将采用函数调用方式来调用目标功能组件；
第二种情形：用户程序与目标功能组件在用户态的不同用户进程中，此时，用户程序将采用RPC方式来调用目标功能组件；
第三种情形：目标功能组件在内核中，此时，用户程序将采用系统调用(system call)方式调用目标功能组件。
下面结合图7a至图7c分别针对上述三种情形进行示例性说明。
针对第一种情形，在图7a中，假设在配置阶段目标功能组件已经被配置到第二用户进程中，即与用户程序位于同一用户进程中。假设第二用户进程中包含第三虚拟文件系统，则可以理解的是，在配置阶段，第三虚拟文件系统中会包含目标功能组件对应的文件路径和回调函数的相关信息，同时，在路径管理模块中会包含目标功能组件对应的文件路径和远程过程调用标识(即RPC_ID)。
在用户程序触发包含目标功能组件的文件路径的调用请求后，可以按照先查询用户程序所在用户进程中的虚拟文件系统，再查询路径管理模块的顺序，首先，在第二用户进程中的第三虚拟文件系统中查询到目标功能组件的文件路径，从而确定目标功能组件的目标配置位置为第二用户进程。此时，获取第三虚拟文件系统中存储的与该文件路径对应的回调函数的相关信息，向用户程序发送该回调函数的相关信息，以使用户程序根据该回调函数的相关信息以函数调用的方式调用目标功能组件。
针对第二种情形，在图7b中，假设在配置阶段目标功能组件已经被配置到第一用户进程中，即与用户程序不位于同一用户进程中。假设第一用户进程中包含第一虚拟文件系统，则可以理解的是，在配置阶段，第一虚拟文件系统中会包含目标功能组件对应的文件路径和回调函数的相关信息，同时，在路径管理模块中会包含目标功能组件对应的文件路径和远程过程调用标识(即RPC_ID)。
在用户程序触发包含目标功能组件的文件路径的调用请求后，按照先查询用户程序所在用户进程中的虚拟文件系统，再查询路径管理模块的顺序，首先，在第二用户进程中的第三虚拟文件系统中未查询到目标功能组件的文件路径，但是在用户空间中的路径管理模块中查询到该目标功能组件的文件路径，则确定目标功能组件的目标配置位置为不同于第二用户进程的其他用户进程。此时，获取路径管理模块中存储的与该文件路径对应的远程过程调用标识，向用户程序发送该远程过程调用标识，以使用户程序根据该远程过程调用标识以远程过程调用的方式调用目标功能组件。远程过程调用的方式可以参考现有相关技术，在此不赘述。
针对第三种情形，在图7c中，假设在配置阶段目标功能组件已经被配置到内核中，假设内核中包含第二虚拟文件系统，则可以理解的是，在配置阶段，第二虚拟文件系统 中会包含目标功能组件对应的文件路径和回调函数的相关信息。
在用户程序触发包含目标功能组件的文件路径的调用请求后，如果在查询路径管理模块时发现未在路径管理模块中查询到目标功能组件的文件路径，则直接确定目标功能组件的目标配置位置不是用户进程，而是内核。此时，通知用户程序以系统调用的方式调用目标功能组件。以系统调用方式来调用目标功能组件，简单来说就是：用户程序通过预设的系统调用指令使自己从用户态陷入到内核态，之后，在内核态查询第二虚拟文件系统中与目标功能组件对应的回调函数的相关信息，基于该回调函数的相关信息调用目标功能组件。
实际应用中，系统调用的方式由于涉及到频繁的用户态与内核态之间的转换，运行效率较低。远程过程调用的方式是一种进程间通信方式，相比于用户进程内的函数调用方式也会消耗更多的资源，运行效率较低。基于本发明实施例提供的功能组件处理方案，用户可以按需决策功能组件的配置位置，可以将功能组件配置在用户态(用户空间)或者内核态(内核)，还可以进一步将不同功能组件配置在用户态的同一用户进程内，以便于提高运行效率。
图6实施例所提供的调用过程承接于图4a所示实施例中功能组件的配置方案。
为便于理解，归纳概括来说，功能组件的调用过程可以实现为：
接收用户程序触发的调用请求，调用请求中包括目标功能组件对应的文件路径，用户程序位于用户空间中的第一用户进程；
根据目标功能组件对应的文件路径，确定目标功能组件的目标配置位置，该目标配置位置为如下任一种：内核，第一用户进程，用户空间中的第二用户进程；
通知所述用户程序以与目标配置位置对应的调用方式调用目标功能组件。
详细的调用过程可以参考前述实施例中的相关说明，在此不赘述。
以下将详细描述本发明的一个或多个实施例的功能组件处理装置。本领域技术人员可以理解，这些功能组件处理装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。
图8为本发明一实施例提供的功能组件处理装置的结构示意图，如图8所示，该功能组件处理装置包括：接收模块11、配置模块12。
接收模块11，用于获取配置请求，所述配置请求中包括操作系统中目标功能组件的标识以及所述目标功能组件在所述操作系统中的目标配置位置。
配置模块12，用于将所述目标功能组件配置到所述目标配置位置，所述目标配置位置位于用户空间或内核；在所述目标配置位置对应的虚拟文件系统中生成所述目标功能组件的注册信息。
可选地，所述装置还包括：获取模块，用于获取安装所述操作系统的设备的参数信息；输出与所述参数信息对应的配置建议，所述配置建议指示所述操作系统中包含的多 个功能组件各自对应的推荐配置位置。
其中，可选地，所述参数信息包括应用场景类型和/或设备处理能力。
可选地，所述目标配置位置为用户空间中的第一用户进程，配置模块12具体用于：在所述第一用户进程中的第一虚拟文件系统中写入所述目标功能组件对应的文件路径和回调函数的相关信息；以及，在所述用户空间中的路径管理模块中写入所述目标功能组件对应的文件路径和远程过程调用标识。
其中，可选地，所述第一用户进程中配置有多个功能组件，所述多个功能组件中包括所述目标功能组件。所述多个功能组件具有搭配使用关系。
可选地，所述目标配置位置为内核，配置模块12具体用于：在所述内核中的第二虚拟文件系统中写入所述目标功能组件对应的文件路径和回调函数的相关信息。
可选地，所述装置还包括：调用模块，用于通过所述接收模块11接收第二用户进程中的用户程序触发的调用请求，所述调用请求中包括所述目标功能组件对应的文件路径；根据所述目标功能组件对应的文件路径，确定所述目标功能组件的目标配置位置，所述注册信息中包括所述文件路径；通知所述用户程序以与所述目标配置位置对应的调用方式调用所述目标功能组件。
其中，可选地，调用模块具体用于：若在所述第二用户进程中的第三虚拟文件系统中查询到所述文件路径，则确定所述目标功能组件的目标配置位置为所述第二用户进程；获取所述第三虚拟文件系统中存储的与所述文件路径对应的回调函数的相关信息，所述第三虚拟文件系统中存储的注册信息包括所述目标功能组件对应的文件路径和回调函数的相关信息；向所述用户程序发送所述回调函数的相关信息，以使所述用户程序根据所述回调函数的相关信息以函数调用的方式调用所述目标功能组件。
其中，可选地，调用模块具体用于：若在所述用户空间中的路径管理模块中查询到所述文件路径，则确定所述目标功能组件的目标配置位置为其他用户进程；获取所述路径管理模块中存储的与所述文件路径对应的远程过程调用标识，所述路径管理模块中存储的注册信息包括所述目标功能组件对应的文件路径和远程过程调用标识；向所述用户程序发送所述远程过程调用标识，以使所述用户程序根据所述远程过程调用标识以远程过程调用的方式调用所述目标功能组件。
其中，可选地，调用模块具体用于：若在所述用户空间中的路径管理模块中未查询到所述文件路径，则确定所述目标功能组件的目标配置位置为内核；通知所述用户程序以系统调用的方式调用所述目标功能组件。
图8所示功能组件处理装置可以执行前述实施例提供的方法，本实施例未详细描述的部分，可参考前述实施例的相关说明，在此不再赘述。
在一个可能的设计中，上述图8所示的功能组件处理装置的结构可实现为电子设备。如图9所示，该电子设备可以包括：处理器21、存储器22、操作系统23。其中，存储 器22上存储有可执行代码，当所述可执行代码被处理器21执行时，至少使处理器21可以实现如前述实施例中提供的功能组件处理。
该电子设备的结构中还可以包括诸如I/O接口、通信接口等接口。
另外，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行前述实施例中提供的功能组件处理。
以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的各个模块可以是或者也可以不是物理上分开的。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现，当然也可以通过硬件和软件结合的方式来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以计算机产品的形式体现出来，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (11)

  1. 一种功能组件处理方法，其特征在于，操作系统包括内核和用户空间，所述内核以及所述用户空间的各用户进程中均配置有虚拟文件系统；所述方法包括：
    获取配置请求，所述配置请求中包括操作系统中目标功能组件的标识以及所述目标功能组件在所述操作系统中的目标配置位置；
    将所述目标功能组件配置到所述目标配置位置，所述目标配置位置位于用户空间的用户进程或内核；
    在所述目标配置位置对应的虚拟文件系统中生成所述目标功能组件的注册信息。
  2. 根据权利要求1所述的方法，其特征在于，所述目标配置位置为用户空间中的第一用户进程，所述在所述目标配置位置对应的虚拟文件系统中生成所述目标功能组件的注册信息，包括：
    在所述第一用户进程中的第一虚拟文件系统中写入所述目标功能组件对应的文件路径和回调函数的相关信息；
    在所述用户空间中的路径管理模块中写入所述目标功能组件对应的文件路径和远程过程调用标识；
    或者，
    所述目标配置位置为内核，所述在所述目标配置位置对应的虚拟文件系统中生成所述目标功能组件的注册信息，包括：
    在所述内核中的第二虚拟文件系统中写入所述目标功能组件对应的文件路径和回调函数的相关信息。
  3. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    接收第二用户进程中的用户程序触发的调用请求，所述调用请求中包括所述目标功能组件对应的文件路径；
    根据所述目标功能组件对应的文件路径，确定所述目标功能组件的目标配置位置，所述注册信息中包括所述文件路径；
    通知所述用户程序以与所述目标配置位置对应的调用方式调用所述目标功能组件。
  4. 根据权利要求3所述的方法，其特征在于，所述根据所述目标功能组件对应的文件路径，确定所述目标功能组件的目标配置位置，包括：
    若在所述第二用户进程中的第三虚拟文件系统中查询到所述文件路径，则确定所述目标功能组件的目标配置位置为所述第二用户进程；
    所述通知所述用户程序以与所述目标配置位置对应的调用方式调用所述目标功能组件，包括：
    获取所述第三虚拟文件系统中存储的与所述文件路径对应的回调函数的相关信息，所述第三虚拟文件系统中存储的注册信息包括所述目标功能组件对应的文件路径和回调函数的相关信息；
    向所述用户程序发送所述回调函数的相关信息，以使所述用户程序根据所述回调函数的相关信息以函数调用的方式调用所述目标功能组件。
  5. 根据权利要求3所述的方法，其特征在于，所述根据所述目标功能组件对应的文件路径，确定所述目标功能组件的目标配置位置，包括：
    若在所述第二用户进程中的第三虚拟文件系统中未查询到所述文件路径，在所述用户空间中的路径管理模块中查询到所述文件路径，则确定所述目标功能组件的目标配置位置为其他用户进程；
    所述通知所述用户程序以与所述目标配置位置对应的调用方式调用所述目标功能组件，包括：
    获取所述路径管理模块中存储的与所述文件路径对应的远程过程调用标识，所述路径管理模块中存储的注册信息包括所述目标功能组件对应的文件路径和远程过程调用标识；
    向所述用户程序发送所述远程过程调用标识，以使所述用户程序根据所述远程过程调用标识以远程过程调用的方式调用所述目标功能组件。
  6. 根据权利要求3所述的方法，其特征在于，所述根据所述目标功能组件对应的文件路径，确定所述目标功能组件的目标配置位置，包括：
    若在所述用户空间中的路径管理模块中未查询到所述文件路径，则确定所述目标功能组件的目标配置位置为内核；
    所述通知所述用户程序以与所述目标配置位置对应的调用方式调用所述目标功能组件，包括：
    通知所述用户程序以系统调用的方式调用所述目标功能组件。
  7. 一种功能组件处理方法，其特征在于，操作系统包括内核和用户空间，所述内核以及所述用户空间的各用户进程中均配置有虚拟文件系统；所述方法包括：
    确定位于所述操作系统中第一配置位置的目标功能组件；
    将所述目标功能组件配置到第二配置位置，所述第一配置位置和所述第二配置位置分别位于所述用户空间的用户进程或所述内核，所述第一配置位置和所述第二配置位置不同；
    在所述第二配置位置对应的虚拟文件系统中生成所述目标功能组件的注册信息。
  8. 一种功能组件处理方法，其特征在于，操作系统包括内核和用户空间，所述方法包括：
    接收用户程序触发的调用请求，所述调用请求中包括目标功能组件对应的文件路径，所述用户程序位于所述用户空间中的第一用户进程；
    根据所述目标功能组件对应的文件路径，确定所述目标功能组件的目标配置位置，所述目标配置位置为如下任一种：所述内核，所述第一用户进程，所述用户空间中的第二用户进程；
    通知所述用户程序以与所述目标配置位置对应的调用方式调用所述目标功能组件。
  9. 一种非暂时性机器可读存储介质，其特征在于，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求1至6或权利要求7或权利要求8中任一项所述的功能组件处理方法。
  10. 一种电子设备，其特征在于，包括：存储器、处理器、操作系统；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1至6或权利要求7或权利要求8中任一项所述的功能组件处理方法。
  11. 一种操作系统，其特征在于，包括：
    内核和用户空间；
    所述用户空间的各用户进程中均配置有虚拟文件系统；所述用户空间中配置有路径管理模块；
    所述内核中配置有虚拟文件系统；
    所述用户空间的目标用户进程中包含用户配置的至少一个第一功能组件，所述目标用户进程中的虚拟文件系统中包含所述至少一个第一功能组件的第一注册信息；
    所述路径管理模块中包含所述用户空间内的各用户进程中所配置的功能组件的第二注册信息；
    所述内核中包含用户配置的至少一个第二功能组件，所述内核中的虚拟文件系统中包含所述至少一个第二功能组件的注册信息。
PCT/CN2022/086515 2021-04-21 2022-04-13 功能组件处理方法、介质、设备和操作系统 WO2022222809A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110432412.2 2021-04-21
CN202110432412.2A CN115220860A (zh) 2021-04-21 2021-04-21 功能组件处理方法、介质、设备和操作系统

Publications (1)

Publication Number Publication Date
WO2022222809A1 true WO2022222809A1 (zh) 2022-10-27

Family

ID=83604652

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/086515 WO2022222809A1 (zh) 2021-04-21 2022-04-13 功能组件处理方法、介质、设备和操作系统

Country Status (2)

Country Link
CN (1) CN115220860A (zh)
WO (1) WO2022222809A1 (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100458710C (zh) * 2003-05-09 2009-02-04 太阳微系统公司 在操作系统分区间进行进程间通信的方法和装置
CN103106260A (zh) * 2013-01-25 2013-05-15 南开大学 一种面向角色的虚拟文件系统的建立方法
CN103995939A (zh) * 2014-05-30 2014-08-20 广东顺德中山大学卡内基梅隆大学国际联合研究院 一种基于arm与fpga的动态可重构嵌入式系统
US8954958B2 (en) * 2010-01-11 2015-02-10 Code Systems Corporation Method of configuring a virtual application
CN105955674B (zh) * 2016-06-16 2019-02-12 北京航空航天大学 虚拟机磁盘镜像模块化快速组装方法、装置和系统
CN108614718B (zh) * 2018-04-25 2019-09-13 新华三信息技术有限公司 启动操作系统的方法、装置和实现装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100458710C (zh) * 2003-05-09 2009-02-04 太阳微系统公司 在操作系统分区间进行进程间通信的方法和装置
US8954958B2 (en) * 2010-01-11 2015-02-10 Code Systems Corporation Method of configuring a virtual application
CN103106260A (zh) * 2013-01-25 2013-05-15 南开大学 一种面向角色的虚拟文件系统的建立方法
CN103995939A (zh) * 2014-05-30 2014-08-20 广东顺德中山大学卡内基梅隆大学国际联合研究院 一种基于arm与fpga的动态可重构嵌入式系统
CN105955674B (zh) * 2016-06-16 2019-02-12 北京航空航天大学 虚拟机磁盘镜像模块化快速组装方法、装置和系统
CN108614718B (zh) * 2018-04-25 2019-09-13 新华三信息技术有限公司 启动操作系统的方法、装置和实现装置

Also Published As

Publication number Publication date
CN115220860A (zh) 2022-10-21

Similar Documents

Publication Publication Date Title
US8661410B2 (en) Managed enterprise software components as dynamic services
US20030135850A1 (en) System of reusable software parts and methods of use
US8856734B2 (en) Type-safe dependency injection of services into enterprise components
EP2843552B1 (en) Method and system for executing callback functions delivered via a communication between a user-space application and the operating system kernel
CN106843937B (zh) 一种通知对应App的调起方法及装置
JP2007328782A (ja) カーネル間でカーネル・サービスを共用するための方法、装置、およびコンピュータ・プログラム
CN107203465B (zh) 系统接口测试方法及装置
CN111221630B (zh) 业务流程处理方法、装置、设备、可读存储介质及系统
EP3582125A1 (en) System and methods with reduced complexity in the integration of exposed information models with applications
CN113626102A (zh) 一种数据处理方法、装置、电子设备及存储介质
US9632897B2 (en) Monitoring components in a service framework
US8738755B2 (en) Providing external access to service versions via a bundle framework
US20100299652A1 (en) Apparatus and method for managing components in sca system
WO2022222809A1 (zh) 功能组件处理方法、介质、设备和操作系统
US8051191B2 (en) Ethernet extensibility
JP5067723B2 (ja) 情報処理装置、情報処理方法およびプログラム
CN107632893B (zh) 消息队列处理方法及装置
CN112130900B (zh) 一种bmc的用户信息管理方法、系统、设备以及介质
JP5382624B2 (ja) マルチプロセッサ制御装置、その方法及びそのプログラム
JP4063573B2 (ja) デバイスドライバの組み込み・実行方式、組み込み・実行方法、及びプログラム
CN110309000B (zh) 应用更新提示方法及终端设备
WO2019134286A1 (zh) 一种路径检测方法、电子设备及可读存储介质
US10289691B2 (en) Dynamic replication of networked files
CN117032818A (zh) 一种基本输入输出系统bios选项配置方法和装置
CN116860479A (zh) 信息处理方法、装置、电子设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22790917

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22790917

Country of ref document: EP

Kind code of ref document: A1