WO2025201178A1 - 一种系统调用方法和装置 - Google Patents

一种系统调用方法和装置

Info

Publication number
WO2025201178A1
WO2025201178A1 PCT/CN2025/083868 CN2025083868W WO2025201178A1 WO 2025201178 A1 WO2025201178 A1 WO 2025201178A1 CN 2025083868 W CN2025083868 W CN 2025083868W WO 2025201178 A1 WO2025201178 A1 WO 2025201178A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
thread
service request
cross
request
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.)
Pending
Application number
PCT/CN2025/083868
Other languages
English (en)
French (fr)
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 Yinwang Intelligent Technology Co Ltd
Original Assignee
Shenzhen Yinwang Intelligent 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 Yinwang Intelligent Technology Co Ltd filed Critical Shenzhen Yinwang Intelligent Technology Co Ltd
Publication of WO2025201178A1 publication Critical patent/WO2025201178A1/zh
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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/48—Program initiating; Program switching, e.g. by interrupt
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06F2009/45583—Memory management, e.g. access or allocation

Definitions

  • the present application relates to the field of computer technology, and in particular to a system call method and device.
  • the functional safety OS of the computing platform in some designs is based on embedded OS solutions such as QNX
  • the functional safety OS of the computing platform in other designs is developed based on the Linux kernel solution.
  • computing platforms based on embedded OS solutions such as QNX are unable to meet the development requirements of autonomous driving-related applications in functional safety OS for a rich ecosystem and rapid iteration.
  • the functional safety OS relies on proxy mechanisms and proxy threads, and is strongly dependent on the Linux kernel in the general OS. Once the Linux kernel fails, the entire functional safety OS will be unable to run, making it difficult to meet the high functional safety requirements of the vehicle.
  • the present application provides a system call method and apparatus for enabling a first OS to efficiently reuse the ecology of a second OS in a scenario where multiple systems coexist on a computing node, thereby ensuring the system performance of the entire computing node as much as possible.
  • the service request is released from the strong binding relationship with the thread state, so that the second OS side can allocate an available first thread to the service request in real time, thereby reducing the system noise floor (further reducing the resource usage of the second OS) and improving the performance of the entire system.
  • management information such as a service identifier
  • the first system call request also includes the system call parameters associated with the first service
  • the first OS sends a service request to the second OS based on the service identifier, which may include: the first OS applies for a first memory space from a shared memory, and stores the system call parameters associated with the first service in the first memory space; the first OS sends the service request to the second OS through the shared memory, where the service request includes the service identifier and a first address, and the first address is the storage address of the system call parameters associated with the first service in the first memory space.
  • a secure shared channel between the first OS and the second OS can be implemented through shared memory to pass information such as system call parameters without status to the second OS, so that the first thread of the second OS can process the service request when running.
  • the first thread processes the service request, including: when the first thread runs on the second OS, reading the system call parameters associated with the first service from the first memory space according to the first address, and processing the service request according to the system call parameters.
  • the first OS can detect whether the second OS is faulty. If not, the first OS can send a cross-OS system service request to the second OS to process the service request using system resources on the second OS side.
  • a checkpoint can be set on the first processing node to enable the first processing node to check the status of the second OS and control the subsequent execution process according to the check result. For example, when the second OS is in a faulty state, the first processing node saves the relevant context and then goes into sleep mode to prevent the service request sent by the first processing node during the second OS fault from being unable to be answered, thereby affecting the continuous operation of tasks or functions on the first OS side.
  • the first OS can also autonomously restore the context of the relevant task after the fault is recovered on the second OS side, so as to re-execute the task and realize cross-OS system calls to resources or services provided by the second OS.
  • the method further includes: the first processing node reads the context information associated with the service request from the shared memory and wakes up the second thread; the second thread re-sends the service request to the second OS based on the context information associated with the service request.
  • a second APP is also running on the first OS, and the first OS obtains status information of the second OS, including: the second APP periodically initiating a second system call request; the first OS sends a service request to the second OS in response to the second system call request, and obtains the status information of the second OS based on the response information of the second OS to the service request.
  • the method may further include: the second OS obtains the demand information of the first APP for the thread that implements the first service, and releases at least one thread among the multiple threads based on the demand information, or creates at least one new thread for the multiple threads based on the demand information.
  • the computing node provides different virtual operating environments through virtual machines, and the first OS and the second OS run in different virtual operating environments of the computing node.
  • the computing node can also adopt a multi-domain chip, and the first OS and the second OS can correspond to different domains respectively.
  • the first OS is called a functional safety domain, which focuses more on the purpose of functional safety.
  • the second OS is called a general domain, which pays more attention to general capabilities.
  • the computing node can also adopt a dual-chip architecture, and the first OS and the second OS can be deployed on the processors of the two chips respectively, and the information interaction between the first OS and the second OS is realized through network communication, so that the entire communication system can meet the optimal state of functional safety, performance, and ecology as much as possible.
  • the first APP also provides a second service by calling the first OS when running, wherein the first APP includes at least one APP related to autonomous driving, and the at least one APP is used to provide at least one of the following services: perception service, fusion processing service or regulation and control service; the second service includes at least one of the scheduling service, process management service or memory management service involved in the autonomous driving related APP, and the first service includes at least one of the file management, interruption management or communication management involved in the autonomous driving related APP.
  • the present application provides a cross-system call method, which is applied to a first operating system OS, the first OS is deployed on a first processor, the first processor is set on a first chip, and a first APP is running on the first OS.
  • the method may include: the first APP initiates a cross-system call request, the cross-system call request includes a service identifier of a first service, the first service is provided by a second OS, the second OS is deployed on a second processor, and the second processor is set on a second chip; the first OS sends a cross-system service request to the second OS according to the service identifier, the cross-system service request is used to request the second OS to allocate an available first thread, and the first thread is used to process the cross-system service request.
  • the method also includes: the first OS obtains status information of the second OS, and the status information includes a fault state or a non-fault state; the first OS sends a cross-system service request to the second OS according to the service identifier, including: if the second OS is in a non-fault state, the first OS sends a service request to the second OS according to the service identifier.
  • the first OS includes a first processing node, and the first processing node is at least used to send the cross-system service request to the second OS in response to the cross-system call request.
  • the method also includes: the first processing node determines whether the second OS is in a fault state; wherein, if the first processing node determines that the second OS is in a fault state before the first APP initiates the cross-system call request, the method also includes: the first processing node stores the context information associated with the first system call request in a storage medium accessible to the first OS and then sleeps.
  • the first OS includes a second thread associated with the first APP
  • the first processing node is used to manage the second thread
  • the second thread is used to send the cross-system service request to the second OS.
  • the method also includes: the second thread determines whether the second OS is in a fault state; wherein, if the second thread determines that the second OS is in a fault state during the process of sending the cross-system service request to the second OS, the method also includes: the second thread stores the context information associated with the service request in the storage medium and then sleeps.
  • the method further includes: the first processing node reads the context information associated with the cross-system service request from the storage medium and wakes up the second thread; the second thread re-sends the cross-system service request to the second OS based on the context information associated with the cross-system service request.
  • a second APP is also running on the first OS, and the first OS obtains the status information of the second OS, including: the second APP periodically initiates a cross-system call request; the first OS sends a cross-system service request to the second OS in response to the cross-system call request, and obtains the status information of the second OS based on the response information of the second OS to the cross-system service request.
  • the first APP also provides a second service by calling the first OS during operation, wherein the first APP includes at least one APP related to autonomous driving, and the at least one APP is used to provide at least one of the following services: perception service, fusion processing service or regulation and control service; the second service includes at least one of the scheduling service, process management service or memory management service involved in the autonomous driving related APP, and the first service includes at least one of the file management, interruption management or communication management involved in the autonomous driving related APP.
  • the present application provides a communication device, comprising: a communication interface for communicating with other devices; a processor coupled to the communication interface, so that the communication device executes the method described in the first aspect and any implementation of the first aspect, or executes the method described in the second aspect and any possible implementation of the second aspect, or executes the method described in the third aspect and any possible implementation of the third aspect.
  • the present application provides a chip system comprising at least one processor and an interface circuit, wherein the processor is used to execute instructions and/or data interaction through the interface circuit, so that the chip system executes the method described in the first aspect and any implementation of the first aspect, or executes the method described in the second aspect and any possible implementation of the second aspect, or executes the method described in the third aspect and any possible implementation of the third aspect.
  • the present application provides a vehicle comprising a computing node, wherein the computing node is used to implement the method described in the first aspect and any implementation of the first aspect, or to implement the method described in the second aspect and any possible implementation of the second aspect, or to implement the method described in the third aspect and any possible implementation of the third aspect.
  • the present application provides a computer-readable storage medium, including a program or instruction.
  • the program or instruction When the program or instruction is executed, the method described in the first aspect and any implementation of the first aspect is executed, or the method described in the second aspect and any possible implementation of the second aspect is executed, or the method described in the third aspect and any possible implementation of the third aspect is executed.
  • the present application provides a computer program product.
  • the computer executes the method described in the first aspect and any implementation of the first aspect, or executes the method described in the second aspect and any possible implementation of the second aspect, or executes the method described in the third aspect and any possible implementation of the third aspect.
  • an embodiment of the present application provides a terminal device, comprising a unit for implementing the method described in the first aspect and any possible design of the first aspect, or a unit for implementing the method described in the second aspect and any possible design of the second aspect.
  • the terminal device includes, but is not limited to: intelligent transportation equipment (such as cars, ships, drones, trains, trucks, etc.), intelligent manufacturing equipment (such as robots, industrial equipment, intelligent logistics, smart factories, etc.), and intelligent terminals (mobile phones, computers, tablet computers, PDAs, desktops, headphones, speakers, wearable devices, vehicle-mounted devices, etc.).
  • FIG2 shows a schematic diagram of the design architecture of an operating system based on a macro kernel
  • FIG3 shows a schematic diagram of a design architecture of a microkernel-based operating system
  • FIG4 shows a schematic diagram of the architecture of a computing platform based on an embedded OS solution such as QNX;
  • FIG8 is a schematic diagram showing a flow chart of a system calling method according to an embodiment of the present application.
  • FIGS. 10-11 are schematic flow charts showing different fault detection methods according to embodiments of the present application.
  • FIG14 shows a schematic diagram of a communication device according to an embodiment of the present application.
  • FIG15 shows a schematic diagram of a communication device according to an embodiment of the present application.
  • a hypervisor also known as a virtual machine monitor (VMM) is software, firmware, or hardware used to create and execute virtual machines.
  • VMM virtual machine monitor
  • the computer used by the hypervisor to execute one or more virtual machines is called the host machine, while these virtual machines are called guest machines.
  • the hypervisor provides a virtual operating platform to execute guest operating systems (guest OSs) and is responsible for managing the execution phase of other guest OSes. These guest OSes share virtualized hardware resources.
  • guest OSs guest operating systems
  • virtual machine 1 and virtual machine 2 can be executed separately based on the virtualization hypervisor.
  • Virtual machine 1 can include the kernel of operating system 1, which can run application 1.
  • Virtual machine 2 can include the kernel of operating system 2, which can run application 2.
  • EL0 is the user level, or non-privileged mode, used to run applications (APPs), with limited access to other resources (insufficient permissions).
  • EL1 is the kernel level, or privileged mode, used to run the operating system kernel and access all system resources.
  • EL2 and EL3 are virtualization extension levels. EL2 is used to run the hypervisor, while EL3 is used to run the hypervisor in the secure world, secure mode.
  • the processor usually only allows EL0 and EL1 modes, which are often called user mode (corresponding to EL0) and kernel mode (corresponding to EL1).
  • Kernel state is the core area where the operating system runs, which controls the computer's hardware resources and provides a running environment for upper-level applications.
  • kernel mode the central processing unit (CPU) can execute all instructions and access all hardware resources. This mode has the highest level of privileges and is primarily used for running and managing the operating system kernel.
  • the CPU can only execute a privileged portion of the instruction set and cannot directly access hardware resources. In this mode, operating permissions are relatively low and it is mainly used to run the user's own programs.
  • User state is the embodiment of the application activity space. Applications request and use the services provided by the operating system through system calls and other means.
  • a process In user mode, a process is not allowed to execute privileged instructions, such as stopping the processor, changing mode bits, or initiating IO operations.
  • privileged instructions such as stopping the processor, changing mode bits, or initiating IO operations.
  • the data and instructions of user mode programs are all executed in their own virtual address space.
  • Switching between user mode and kernel mode can occur in a variety of ways, including but not limited to:
  • a process In computers, a process is a running instance of a program. When a program starts, the operating system creates a process for it.
  • a process is the basic unit of resource allocation in a computer, containing information such as the code, data, and stack required for program execution.
  • a process can have multiple threads, each of which can execute code independently but share the process's memory and other resources. Each process has a unique process identifier (ID).
  • ID process identifier
  • Processes can communicate with other processes, for example, by exchanging data through associations, shared memory, and sockets.
  • a thread is the smallest unit of computational scheduling in an operating system and represents an execution flow within a process.
  • a process can contain multiple threads, each of which is an execution unit within the process and can independently perform specific tasks. Within a program, multiple threads can simultaneously execute different tasks, thus achieving concurrent execution. Compared to processes, threads are more lightweight. Because they can share the process's memory and other resources, communication and data sharing between threads are easier and more efficient. Threads can be implemented in a variety of ways, such as user-level threads, kernel-level threads, and lightweight processes. Developers can choose the appropriate threading model based on their needs and goals.
  • Each process usually has two stacks, one in user space and the other in kernel space.
  • the contents of the stack pointer register used by the CPU point to the user stack address.
  • kernel space it points to the kernel stack space address.
  • kernel mode When a process is in user mode, it cannot access kernel space or directly call kernel functions. When a call is required, the process switches to kernel mode.
  • User mode can access kernel resources through system calls, library functions, and shell scripts. This design ensures security and stability, preventing user programs from arbitrarily accessing operating system resources or executing dangerous instructions.
  • context encompasses the environment and state information of program execution, helping programs manage state, control flow, and execution.
  • a context switch is an event that occurs when an operating system manages processes and threads in a multitasking environment. It involves saving the state (i.e., context) of the current task for later restoration and transferring control to the next task. This process involves saving the register contents and program counter of the current task in the process control block, then restoring the context of the next task and continuing execution from the location pointed to by the program counter of the next task.
  • Processes and threads are managed and scheduled by the operating system, and their states can change at any time.
  • a main thread typically appears with the creation of a process.
  • the CPU divides these into two types based on their permissions: user-mode threads and kernel-mode threads.
  • Kernel-state threads also known as kernel-level threads, have higher privileges and do not require system calls for certain operations. Kernel-state threads run in the kernel and are controlled by the kernel.
  • the Linux operating system is an open-source multi-user, multi-tasking operating system.
  • the Linux macro kernel includes multiple basic modules, such as the process management module (or called the process scheduler module), the memory management module, the file system module, the device driver module, the network system module, etc. Relying on hardware such as the CPU, RAM, hard disk, CD, terminal device, network adapter, etc., and using a combination of software and hardware, the various basic modules of the Linux kernel can provide multi-tasking scheduling functions, virtual memory management functions, file directory functions, terminal access functions, and network functions for application tools running in user space.
  • the QNX Neutrino real-time operating system is a distributed, embedded, scalable, and Unix-like real-time operating system that complies with the Portable Operating System Interface (POSIX) specification.
  • QNX provides a board support package (BSP), an RTOS microkernel, a software middleware layer, and an enhanced service layer to support applications.
  • BSP board support package
  • the RTOS microkernel provides only four services: process scheduling, inter-process communication, low-level network communication, and interrupt handling.
  • Drivers, protocol stacks, file systems, and applications all run outside the microkernel in a secure, memory-protected user space. This prevents components from interfering with each other and allows for restart in the event of a failure.
  • In-vehicle intelligent computing platform (hereinafter referred to as computing platform):
  • Autonomous driving vehicles build software and hardware systems around the three major links of perception, decision-making and execution.
  • the on-board intelligent computing platform is the "brain" of the autonomous driving vehicle. It is mainly responsible for completing the recognition and fusion tasks of the perception link and the entire decision-making link, and requires processing massive data and performing complex logical operations.
  • This proxy request must carry the relevant thread context on the secure OS side to describe the thread's execution status.
  • the Linux kernel then waits for the proxy request to be processed.
  • the secure APP kernel state is always blocked and waiting. Once it receives a proxy request sent by the secure OS, it runs a specific thread based on the relevant thread context carried in the proxy request, calls the corresponding function of the Linux kernel to process the proxy request, and returns the processing result to the secure OS kernel.
  • At least one refers to one or more, and “more” refers to two or more.
  • “And/or” describes the association relationship of associated objects, indicating that three relationships may exist.
  • a and/or B can represent: the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural.
  • the character “/” generally indicates that the previous and next associated objects are in an “or” relationship.
  • At least one of the following items” or similar expressions refers to any combination of these items, including any combination of single items or plural items.
  • At least one of a, b, or c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, c can be single or multiple.
  • the architecture may include at least two operating systems (OS), for example, represented as a first OS and a second OS, and other OSs not shown.
  • OS operating systems
  • the at least two operating systems can be deployed on a multi-domain chip.
  • the chip is divided into different areas or functional blocks, each area or functional block can become a domain, and different domains can have different processor cores, memories, I/O interfaces and other resource configurations.
  • Each domain is responsible for different tasks and functions to achieve different functions or performance requirements.
  • Any of the at least two operating systems can be deployed on the processor core of a domain to achieve more efficient and safer chip operation.
  • the first OS in Figure 7 can be called a functional safety domain, deployed on the processor core of the functional safety domain
  • the second OS is called a general domain, deployed on the processor core of the general domain.
  • the at least two operating systems may be deployed on different chips.
  • the first OS in FIG7 may be deployed on a first processor disposed on a first chip
  • the second OS may be deployed on a second processor disposed on a second chip.
  • the service provided by utilizing the system resources of the second OS may be referred to as the first service
  • the service provided by utilizing the system resources of the first OS may be referred to as the second service
  • the kernel node in the kernel of the first OS that provides the same OS system call service for the first APP is referred to as the second processing node
  • the kernel node in the kernel of the first OS that provides the cross-OS system call service for the first APP is referred to as the first processing node.
  • the first processing node may also be referred to as the client of the cross-OS system call service, which is used to respond to the system cross-OS system call request from the first APP and send a service request to the second OS through the secure shared channel between the first OS and the second OS to apply for the use of the resources or services provided by the second OS.
  • the kernel of the second OS may include a third processing node, which may also be referred to as the server of the cross-OS system call service, which is used to receive the service request from the first OS and allocate an available first thread to the service request from multiple threads of the second OS so that the first thread processes the service request, i.e., provide a cross-OS system call service for the APP on the first OS side.
  • the first APP can re-initiate the system call request based on the context information associated with the system call request, and the first processing node can re-respond to the system call request and send a service request to the second OS. Since the second OS has recovered to a non-faulty state, the service request can be re-received and processed by the second OS side, which does not affect the implementation of the tasks or functions on the first OS side.
  • a second app can be installed and run on the first OS.
  • the second app can be used to trigger the fault self-recovery node in the first OS kernel to detect the running status of the second OS in real time or periodically.
  • the embodiment of the present application does not limit the implementation method of this fault detection mechanism.
  • the above-mentioned self-healing mechanism allows the first OS to independently run security tasks for several minutes even if a fault occurs on the second OS. After the second OS recovers from the fault, the system calls from the first OS to the second OS can self-heal.
  • the second OS can use a Linux system with excellent ecological capabilities to ensure that the entire communication system meets the optimal functional safety, performance, and ecological conditions.
  • the first OS which may also be referred to as a functional safety OS, may run a first app on the first OS, which may include an autonomous driving-related app.
  • the second service provided by the first OS may include at least one of a scheduling service, a process management service, or a memory management service associated with the autonomous driving-related app.
  • the second OS which may also be referred to as a general-purpose OS, may provide a first service including at least one of file management, interrupt management, or communication management associated with the autonomous driving-related app.
  • S810 The first APP initiates a first system call request.
  • the first system call request may include the service identifier of the first service, and the service identifier may be the system call number bound to the first service. If the first APP initiates the first system call request to the first OS, the first system call request may include the service identifier of the second service, and the service identifier may be the system call number bound to the second service. In an optional embodiment, if certain services can be provided by both the first OS and the second OS, the service identifier included in the first system call request may be implemented as a combination of a system call number and a label, and the label may indicate whether it is provided by the first OS or the second OS. Based on the service identifier, the service routing node in the kernel of the first OS can know whether to route the first system service request to the first processing node or the second processing node.
  • S820 The first OS sends a service request to the second OS according to the service identifier.
  • the kernel of the first OS may include a service routing node.
  • the service routing node may identify, based on the service identifier carried in the first system service request, whether the first system service request is specifically initiated for the second service provided by the first OS or for the first service provided by the second OS. If the first system service request is initiated for the first service provided by the second OS, the service routing node may route the first system service request to the first processing node in the kernel of the first OS.
  • the first processing node may send a service request to the second OS based on the service identifier carried in the first system call request.
  • the first processing node may send a service request to the second OS via a network communication channel between the first and second OSs.
  • the service request includes the service identifier of the first service requested by the first APP and the system call parameters associated with the first service, such as the thread identifier of the first APP and the input parameters of the system call function.
  • a third processing node may receive the service request and allocate an available first thread to the service request. When the first thread runs, it may process the service request based on the service identifier of the first service and the system call parameters associated with the first service, utilizing the system resources of the second OS.
  • the first system call request may also include system call parameters associated with the first service, such as the thread identifier of the first APP, the input parameters of the system call function, etc.
  • the secure shared channel between the first OS and the second OS can be implemented as a shared memory between the two.
  • the first OS may also apply for a first memory space from the shared memory, and store the system call parameters associated with the first service in the first memory space, such as the thread identifier of the first APP, the input parameters of the system call function, etc., and the context state information (including various status registers) of the task on the first OS side is not included.
  • S830 The second OS receives the service request and allocates an available first thread from a plurality of threads to the service request.
  • the multiple threads may be kernel threads of the second OS, and the second OS may sequentially select an idle thread as an available first thread to allocate (or called "taking out” or “taking off") to the service request.
  • the multiple kernel threads may be specifically scheduled and managed by a third processing node in the kernel of the second OS.
  • the second OS may create a service thread pool when the third processing node is initialized, and the service thread pool includes multiple kernel threads that can be used to provide cross-system call services for the first OS side.
  • the third processing node may allocate an available first thread to the service request. For example, in FIG7 , if thread 1 is occupied and thread 2 is idle, the third processing node may allocate thread 2 to the service request.
  • S840 The first thread processes the service request.
  • the first thread when the first thread runs on the second OS, it reads the system call parameters associated with the first service from the first memory space according to the first address carried in the service request.
  • the system call parameters do not involve the context state of the first OS task.
  • the first thread does not need to perceive the context state of the first OS task and can directly process the service request according to the system call parameters.
  • the first thread can feedback the processing results to the first processing node through the secure shared channel between the first OS and the second OS, and release the resources applied for this process.
  • the first thread sends a return value to the first processing node through the secure shared channel, that is, the processing result of this system service request, indicating whether it is successful or not.
  • the first processing node will return the return value to the first APP in user state, thereby completing a cross-OS system call service.
  • the kernel thread on the second OS side does not need to be aware of the context state of the first OS task, and does not need to be strongly bound 1:1 with the thread on the first OS side.
  • the service thread on the second OS side can be decoupled from the task on the first OS side, thereby reducing the background noise of the entire system and improving system performance.
  • the checkpoint can be set at the first processing node.
  • the system call method may include the following steps:
  • a first APP initiates a first system call request to request the use of a cross-OS system service.
  • S905 Implement a fault self-recovery mechanism to save the context information associated with the service request.
  • the first processing node can resend the service request to the second OS based on the saved context information. After recovery, the process returns to S903 to detect whether the second OS has failed in real time or periodically at the first processing node.
  • the kernel of the first OS may include a second thread associated with the first APP, and the second thread may be a thread of the first APP running in the kernel state for implementing the task of the first APP, and the first processing node may be used to manage the second thread to make a system call to the second OS.
  • S904 it may be that the second thread determines whether the second OS is in a faulty state. If so, when implementing S905, the second thread saves the context information associated with the service request and then goes to sleep. For example, the second thread may go to sleep after storing the context information associated with the service request in a shared memory (such as a first memory space).
  • the first processing node may read the context information associated with the service request from the shared memory and wake up the second thread.
  • the second thread may resend the service request to the second OS based on the context information associated with the service request.
  • the first processing node sends a service request to the second OS through the stateless system service request module in the secure shared channel to request to call the system service of the second OS.
  • the first processing node can inform the stateless system service request module of the service identifier of the first service to be called, and at the same time apply for a first memory space from the shared memory, and store the system call parameters associated with the first service in the first memory space.
  • the stateless system service request module can send a service request to the second OS based on the service identifier and the first address of the first service.
  • the service request includes the service identifier and the first address, and the first address is the storage address of the system call parameters associated with the first service in the first memory space.
  • the third processing node in the second OS kernel receives the service request and allocates an available first thread from the plurality of kernel threads to the service request.
  • the first thread runs, it reads system call parameters associated with the first service from the shared memory based on the first address carried in the service request and processes the service request based on the system call parameters.
  • the first thread sends the processing result to the first processing node through a secure shared channel and releases the relevant service resources. For example, a return value is sent to indicate success or failure.
  • the relevant service resources may include the running resources corresponding to the first thread, and may also include the system resources of the second OS used by the first thread to process the service request. This embodiment of the present application does not limit this. Accordingly, the first processing node can also send the processing result to the first APP in the user state, that is, complete the processing of this cross-OS system call service.
  • the second processing node in the second OS kernel responds to the same OS system call request from the first APP and uses the system resources of the first OS to provide system services for the first APP.
  • the second app can determine whether it has received the expected return result, such as whether it has received the expected return result within a fixed time interval or whether it has received the expected return result within multiple fixed time intervals. If so, it can be determined that the second OS's status is normal, that is, it is in a non-faulty state. If not, it can be determined that the second OS is in a faulty state.
  • the first processing node controls the second thread to send a service request to the second OS in response to the first system call request and determines that the second OS is in a faulty state
  • the first processing node can instruct the second thread to sleep after storing the context information associated with the service request in the shared memory. If it is determined that the second OS is in a faulty state after the second thread sends a service request to the second OS, the service request may have been received by the second OS. After the second OS recovers from the fault, the second OS can schedule the available first thread for the service request and the first thread can process the service request. This process has no effect on the operation of the process/thread on the first OS side. The first OS only needs to execute the cross-OS system call process of the embodiment of the present application normally, which will not be repeated here.
  • the first OS side also needs to quickly self-heal to re-initiate a system call to the second OS.
  • the self-healing process of the first OS and the second OS may include the following steps:
  • S1201 The second OS recovers from a faulty state to a non-faulty state.
  • the first OS detects that the second OS has recovered from a faulty state to a non-faulty state.
  • the second APP detects that the second OS has recovered from a faulty state to a non-faulty state.
  • S1204 Wake up the task that was dormant when the fault occurred, restore the context state of the task at that time and complete data verification.
  • the first OS can read the context information associated with the first system call request from the shared memory and wake up the first processing node.
  • the first processing node can verify the context information associated with the first system call request based on the management information in the shared memory to verify the integrity of the data before the fault.
  • the first processing node reads the context information associated with the service request from the shared memory and wakes up the second thread.
  • the second thread can verify the context information associated with the service request based on the management information in the shared memory to verify the integrity of the data before the failure.
  • S1205 Enable the awakened task to re-initiate the cross-OS system call service for the second OS.
  • the first APP may re-initiate the first system call request according to the context information associated with the first system call request, and the first processing node re-sends a service request to the second OS in response to the first system call request.
  • the second thread may resend the service request to the second OS based on the context information associated with the service request.
  • the third processing node can re-receive the cross-OS system service request from the first OS and call the available first thread for the service request to process the service request.
  • This process is the same as described above in conjunction with Figures 8 and 9. The specific implementation can be found in the relevant description above and will not be repeated here.
  • the first OS side can also re-execute the cross-system call for the second OS by waking up the dormant nodes and/or threads, thereby improving the robustness and robustness of the entire system.
  • the first OS's support for the standard POSIX interface can be improved.
  • the kernel thread can provide system services in the kernel of the second OS, and the service request from the first OS does not contain thread context state information, so that the APP thread in the first OS can be bound to any general kernel thread of the second OS as a service thread to process cross-OS system service requests, which can effectively reduce the amount of communication data, and at the same time greatly shorten the creation delay of the service thread on the second OS side, and improve the critical path performance of cross-OS system service calls.
  • a fault self-healing mechanism is implemented to enable the APP task of the first OS to run in a self-healing manner, which helps the entire computing node reach a better state that meets functional safety, performance, and ecology.
  • the above method flow is only an example of cross-OS system call service and is not limited in any way.
  • the method is also applicable to initiating a page fault processing process or a maintenance process from the first OS side to the second OS side.
  • the first OS side can reuse the various resources and services provided by the second OS side, so that the first OS can reuse the ecology of the second OS.
  • the first OS supports the ability to reuse the disk file system of the second OS, and the APP file running on the first OS can be saved in the second OS.
  • the APP file can be read from the second OS side to the first OS side using the method of the embodiment of the present application.
  • the first OS supports the ability to reuse the second OS terminal, and the method of the embodiment of the present application can be used to implement the ability to debug the first OS on the second OS side.
  • the embodiment of the present application further provides a communication device for executing the method executed by the first OS or the second OS in the above method embodiment.
  • the relevant features can be found in the above method embodiment and will not be repeated here.
  • a communication device 1300 may include: a first APP 1301 for initiating a first system call request, wherein the first system call request includes a service identifier of a first service; and a transceiver unit 1302 for sending a service request to the second OS based on the service identifier.
  • a communication device 1400 may include: a transceiver unit 1401 for receiving the service request and allocating an available first thread to the service request from multiple threads; and a first thread 1402 for processing the service request.
  • a transceiver unit 1401 for receiving the service request and allocating an available first thread to the service request from multiple threads
  • a first thread 1402 for processing the service request.
  • the division of the various units in the above device is only a division of logical functions. In actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated.
  • the units in the device can be implemented in the form of a processor calling software; for example, the device includes a processor, the processor is connected to a memory, and the memory stores instructions.
  • the processor calls the instructions stored in the memory to implement any of the above methods or realize the functions of the various units of the device, wherein the processor is, for example, a general-purpose processor, such as a central processing unit (CPU) or a microprocessor, and the memory is a memory within the device or a memory outside the device.
  • CPU central processing unit
  • microprocessor a microprocessor
  • the units in the device may be implemented in the form of hardware circuits, and the functions of some or all of the units may be implemented by designing the hardware circuits.
  • the hardware circuits may be understood as one or more processors.
  • the hardware circuit is an application-specific integrated circuit (ASIC), and the functions of some or all of the above units may be implemented by designing the logical relationships between the components within the circuit.
  • the hardware circuit may be implemented by a programmable logic device (PLD).
  • PLD programmable logic device
  • FPGA field programmable gate array
  • All units of the above devices may be implemented entirely by a processor calling software, or entirely by a hardware circuit, or partially by a processor calling software, with the remainder implemented by a hardware circuit.
  • a processor is a circuit with signal processing capabilities.
  • the processor can be a circuit with instruction reading and execution capabilities, such as a CPU, a microprocessor, a graphics processing unit (GPU) (which can be understood as a microprocessor), or a digital signal processor (DSP).
  • the processor can implement certain functions through the logical relationship of a hardware circuit, and the logical relationship of the hardware circuit is fixed or reconfigurable, such as a hardware circuit implemented by an ASIC or PLD, such as an FPGA.
  • the process of the processor loading a configuration document to implement the hardware circuit configuration can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units.
  • it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), a tensor processing unit (TPU), a deep learning processing unit (DPU), etc.
  • NPU neural network processing unit
  • TPU tensor processing unit
  • DPU deep learning processing
  • each unit in the above device can be one or more processors (or processing circuits) configured to implement the above method, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.
  • processors or processing circuits
  • the various units in the above devices can be fully or partially integrated together, or can be implemented independently. In one implementation, these units are integrated together and implemented in the form of a system-on-a-chip (SOC).
  • SOC may include at least one processor for implementing any of the above methods or implementing the functions of the various units of the device.
  • the type of the at least one processor can be different, for example, including a CPU and FPGA, a CPU and an artificial intelligence processor, a CPU and a GPU, etc.
  • connection medium between the processor 1510 and the memory 1520 is not limited in the embodiment of the present application.
  • the processor 1510 may transmit data through the communication interface 1530 when communicating with other devices.
  • the processor 1510 in Figure 15 can call the computer-executable instructions stored in the memory 1520, so that the device 1500 can execute any of the above method embodiments.
  • An embodiment of the present application also relates to a chip system, which includes a processor for calling a computer program or computer instructions stored in a memory so that the processor executes the method of any of the above embodiments.
  • the processor may be coupled to the memory through an interface.
  • the chip system may also directly include a memory, in which a computer program or computer instructions are stored.
  • the memory may be a volatile memory or a nonvolatile memory, or may include both volatile and nonvolatile memory.
  • the nonvolatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory.
  • the volatile memory may be a random access memory (RAM), which is used as an external cache memory.
  • RAM random access memory
  • SRAM static RAM
  • DRAM dynamic RAM
  • SDRAM synchronous DRAM
  • DDR SDRAM double data rate synchronous dynamic random access memory
  • ESDRAM enhanced synchronous dynamic random access memory
  • SLDRAM synchronous link dynamic random access memory
  • DR RAM direct rambus RAM
  • An embodiment of the present application further relates to a processor, which is used to call a computer program or computer instruction stored in a memory so that the processor executes the method described in any of the above embodiments.
  • the processor is an integrated circuit chip with signal processing capabilities.
  • the processor can be an FPGA, a general-purpose processor, a DSP, an ASIC, or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, a system-on-chip (SoC), a CPU, a network processor (NP), a microcontroller unit (MCU), a PLD, or other integrated chip, and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application.
  • the general-purpose processor can be a microprocessor, or the processor can be any conventional processor.
  • the steps of the methods disclosed in the embodiments of the present application can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor.
  • the software module can be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc.
  • the storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.
  • the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
  • a computer-usable storage media including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.
  • These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)

Abstract

一种系统调用方法和装置，该方法中，第一OS上运行有第一应用程序APP，第一APP可以发起第一系统调用请求，所述第一系统调用请求中包括第一服务的服务标识；所述第一OS根据所述服务标识向所述第二OS发送服务请求；所述第二OS接收所述服务请求，并从多个线程中为所述服务请求分配可用的第一线程；所述第一线程对所述服务请求进行处理。该方法有助于在计算节点多系统共存的场景下，使得第一OS能够高效地复用第二OS的生态，尽可能地保障整个计算节点的系统性能。

Description

一种系统调用方法和装置
相关申请的交叉引用
本申请要求在2024年3月25日提交中华人民共和国国家知识产权局、申请号为202410349538.7、发明名称为“一种系统调用方法和装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域，特别涉及一种系统调用方法和装置。
背景技术
随着汽车电子电气(electrical and electronic，E/E)架构的演进，对车辆的计算平台提出了更高的要求。业内逐步开始探索在车辆的计算平台上基于虚拟机构筑双客体操作系统(guest operating system，guest OS)，例如通过虚拟化技术实现在车辆的计算平台同时运行通用OS和功能安全OS的方案。
其中，在一些设计中的计算平台的功能安全OS是基于QNX等嵌入式OS方案，在另一些设计中的计算平台的功能安全OS是基于Linux内核方案进行开发的。但是，受限于QNX所采用的微内核架构以及QNX本身的生态支持能力，基于QNX等嵌入式OS方案的计算平台难以满足功能安全OS中的自动驾驶相关应用对丰富生态、快速迭代的开发诉求。而基于Linux内核方案进行开发的计算平台中，功能安全OS依赖于代理机制和代理线程，并强依赖通用OS中的Linux内核，一旦Linux内核发生故障将会导致整个功能安全OS无法运行，难以满足车辆的高功能安全诉求。
因此，如何在车辆的计算平台上构筑双Guest OS系统，以尽可能地兼顾该计算平台的生态支持能力以及高功能安全诉求等，仍为亟需解决的重要问题。
发明内容
本申请提供一种系统调用方法和装置，用于在计算节点多系统共存的场景下，使得第一OS能够高效地复用第二OS的生态，尽可能地保障整个计算节点的系统性能。
第一方面，本申请提供了一种系统调用方法，该方法可以应用于车辆的计算节点，所述计算节点包括第一操作系统OS和第二OS，所述第一OS上运行有第一应用程序APP，所述方法可以包括：所述第一APP发起第一系统调用请求，所述第一系统调用请求中包括第一服务的服务标识；所述第一OS根据所述服务标识向所述第二OS发送服务请求；所述第二OS接收所述服务请求，并从多个线程中为所述服务请求分配可用的第一线程；所述第一线程对所述服务请求进行处理。
通过上述方法，在多OS系统共存的场景中，通过在来自第一OS的跨OS系统服务请求中只包含少量的管理信息(例如服务标识)、而不包含用于描述线程的执行状态的上下文信息，来将该服务请求与线程状态解除强绑定关系，使得第二OS侧能够实时地为该服务请求分配可用的第一线程，从而降低系统底噪(进一步降低对第二OS的资源占用)，提升整个系统的性能。
结合第一方面，在一种可能的实现方式中，所述第一系统调用请求中还包括所述第一服务关联的系统调用参数，所述第一OS根据所述服务标识向所述第二OS发送服务请求，可以包括：所述第一OS向共享内存申请第一内存空间，并在所述第一内存空间中存储所述第一服务关联的系统调用参数；所述第一OS通过所述共享内存向所述第二OS发送所述服务请求，所述服务请求中包括所述服务标识和第一地址，所述第一地址为所述第一服务关联的系统调用参数在所述第一内存空间中的存储地址。
通过上述方法，可以通过共享内存实现第一OS与第二OS之间的安全共享通道，以向第二OS传递不包含状态的系统调用参数等信息，以使得第二OS的第一线程运行时对该服务请求进行处理。
结合第一方面，在一种可能的实现方式中，所述第一线程对所述服务请求进行处理，包括：所述第一线程在所述第二OS上运行时，根据所述第一地址从所述第一内存空间中读取所述第一服务关联的系统调用参数，并根据所述系统调用参数对所述服务请求进行处理。
结合第一方面，在一种可能的实现方式中，所述方法还可以包括：所述第一OS获取所述第二OS的状态信息，所述状态信息包括故障状态或者非故障状态；所述第一OS根据所述服务标识向所述第二OS发送服务请求，包括：若所述第二OS处于非故障状态，所述第一OS根据所述服务标识向所述第二OS发送服务请求。
通过上述方法，第一OS可以检测第二OS是否故障，若非故障则可以向第二OS发送跨OS系统服务请求，以利用第二OS侧的系统资源对该服务请求进行处理。
结合第一方面，在一种可能的实现方式中，所述第一OS中包括第一处理节点，所述第一处理节点至少用于响应于所述第一系统调用请求向所述第二OS发送所述服务请求，所述方法还可以包括：所述第一处理节点确定所述第二OS是否处于故障状态；其中，若所述第一处理节点在所述第一APP发起所述第一系统调用请求之前确定所述第二OS处于故障状态，所述方法还包括：所述第一处理节点在所述第一OS和所述第二OS的共享内存中存储所述第一系统调用请求关联的上下文信息后休眠。
通过上述方法，基于故障自愈机制，可以在第一处理节点设置检查点，以使第一处理节点对第二OS的状态进行检查和根据检查结果控制后续执行流程，例如，在第二OS处于故障状态的情况下，保存相关上下文后休眠，以免第一处理节点在第二OS故障期间所发送的服务请求无法被应答，影响第一OS侧的任务或功能的持续运行。
结合第一方面，在一种可能的实现方式中，若所述第一处理节点休眠时所述第二OS从故障状态恢复为非故障状态，所述方法还包括：所述第一OS从所述共享内存中读取所述第一系统调用请求关联的上下文信息，并唤醒所述第一处理节点；所述第一APP根据所述第一系统调用请求关联的上下文信息重新发起第一系统调用请求；所述第一处理节点响应于所述第一系统调用请求重新向所述第二OS发送服务请求。
通过上述方法，基于故障自愈机制，第一OS还可以在第二OS侧的故障恢复后，自主地恢复相关任务的上下文，以便重新执行该任务，实现对第二OS提供的资源或服务的跨OS系统调用。
结合第一方面，在一种可能的实现方式中，所述第一OS中包括所述第一APP关联的第二线程，所述第一处理节点用于管理所述第二线程，所述第二线程用于向所述第二OS发送所述服务请求，所述方法还包括：所述第二线程确定所述第二OS是否处于故障状态；其中，若所述第二线程在向所述第二OS发送所述服务请求的过程中确定所述第二OS处于故障状态，所述方法还包括：所述第二线程在所述共享内存中存储所述服务请求关联的上下文信息后休眠。
通过上述方法，基于故障自愈机制，还可以在用于执行任务的第二线程设置检查点，以使该第二线程对第二OS的状态进行检查和根据检查结果控制后续执行流程，例如，在第二OS处于故障状态的情况下，保存相关上下文后休眠，以免第二线程在第二OS故障期间所发送的服务请求无法被应答，影响第一OS侧的任务或功能的持续运行。
结合第一方面，在一种可能的实现方式中，若所述第二线程休眠时所述第二OS从故障状态恢复为非故障状态，所述方法还包括：所述第一处理节点从所述共享内存中读取所述服务请求关联的上下文信息，并唤醒所述第二线程；所述第二线程基于所述服务请求关联的上下文信息重新向所述第二OS发送服务请求。
通过上述方法，基于故障自愈机制，第一OS还可以在第二OS侧的故障恢复后，自主地恢复相关任务的上下文，以便重新执行该任务，实现对第二OS提供的资源或服务的跨OS系统调用。
结合第一方面，在一种可能的实现方式中，所述第一OS上还运行有第二APP，所述第一OS获取所述第二OS的状态信息，包括：所述第二APP周期性地发起第二系统调用请求；所述第一OS响应于所述第二系统调用请求向所述第二OS发送服务请求，并根据所述第二OS对所述服务请求的应答信息获取所述第二OS的状态信息。
通过上述方法，还可以在第一OS启动第二APP的进程作为常驻进程，以周期性地检测第二OS的状态，从而提升整个系统的健壮性和鲁棒性。
结合第一方面，在一种可能的实现方式中，所述方法还可以包括：所述第二OS获取所述第一APP对实现所述第一服务的线程的需求信息，并根据所述需求信息释放所述多个线程中的至少一个线程，或者，根据所述需求信息为所述多个线程新建至少一个线程。
通过上述方法，在第二OS侧以线程池的方式管理多个服务线程，该方法支持对该多个线程的动态地扩容或者收缩，以在满足第一OS侧的跨OS系统调用需求的情况下，减少对第二OS侧的资源的占用。
结合第一方面，在一种可能的实现方式中，所述计算节点通过虚拟机提供不同的虚拟运行环境，所述第一OS和所述第二OS运行在所述计算节点的不同虚拟运行环境中。在另一个实施例中，该计算节点还可以采用多域芯片，第一OS和第二OS可以分别对应于不同的域，例如第一OS称为功能安全域，更加注重功能安全的目的。第二OS称为通用域，更加关注通用能力。在另一个实施例中，该计算节点还可以采用双芯片架构，第一OS和第二OS可以分别部署在这两个芯片的处理器上，通过网络通信实现第一OS与第二OS之间的信息交互，以使得整个通信系统尽可能满足功能安全、性能、生态的最佳状态。
结合第一方面，在一种可能的实现方式中，所述第一APP运行时还通过调用所述第一OS提供第二服务，其中，所述第一APP包括自动驾驶相关的至少一个APP，所述至少一个APP用于提供以下的至少一种服务：感知服务、融合处理服务或者规控服务；所述第二服务包括所述自动驾驶相关APP涉及的调度服务、进程管理服务或者内存管理服务中的至少一种，所述第一服务包括所述自动驾驶相关APP涉及的文件管理、中断管理或者通信管理中的至少一种。
第二方面，本申请提供了一种跨系统调用方法，应用于第一操作系统OS，所述第一OS部署在第一处理器，所述第一处理器设置在第一芯片上，所述第一OS上运行有第一APP，所述方法可以包括：所述第一APP发起跨系统调用请求，所述跨系统调用请求中包括第一服务的服务标识，所述第一服务由第二OS提供，所述第二OS部署在第二处理器，所述第二处理器设置在第二芯片上；所述第一OS根据所述服务标识向所述第二OS发送跨系统服务请求，所述跨系统服务请求用于请求所述第二OS分配可用的第一线程，所述第一线程用于对所述跨系统服务请求进行处理。
结合第二方面，在一种可能的实现方式中，所述第一芯片和所述第二芯片之间基于网络通信，所述第一OS根据所述服务标识向所述第二OS发送跨系统服务请求，包括：所述第一OS通过所述网络向所述第二OS发送跨系统服务请求，所述跨系统服务请求中包括所述服务标识和所述第一服务关联的跨系统调用参数。
结合第二方面，在一种可能的实现方式中，所述方法还包括：所述第一OS获取所述第二OS的状态信息，所述状态信息包括故障状态或者非故障状态；所述第一OS根据所述服务标识向所述第二OS发送跨系统服务请求，包括：若所述第二OS处于非故障状态，所述第一OS根据所述服务标识向所述第二OS发送服务请求。
结合第二方面，在一种可能的实现方式中，所述第一OS中包括第一处理节点，所述第一处理节点至少用于响应于所述跨系统调用请求向所述第二OS发送所述跨系统服务请求，所述方法还包括：所述第一处理节点确定所述第二OS是否处于故障状态；其中，若所述第一处理节点在所述第一APP发起所述跨系统调用请求之前确定所述第二OS处于故障状态，所述方法还包括：所述第一处理节点在所述第一OS可访问的存储介质中存储所述第一系统调用请求关联的上下文信息后休眠。
结合第二方面，在一种可能的实现方式中，若所述第一处理节点休眠时所述第二OS从故障状态恢复为非故障状态，所述方法还包括：所述第一OS从所述存储介质中读取所述跨系统调用请求关联的上下文信息，并唤醒所述第一处理节点；所述第一APP根据所述跨系统调用请求关联的上下文信息重新发起跨系统调用请求；所述第一处理节点响应于所述跨系统调用请求重新向所述第二OS发送跨系统服务请求。
结合第二方面，在一种可能的实现方式中，所述第一OS中包括所述第一APP关联的第二线程，所述第一处理节点用于管理所述第二线程，所述第二线程用于向所述第二OS发送所述跨系统服务请求，所述方法还包括：所述第二线程确定所述第二OS是否处于故障状态；其中，若所述第二线程在向所述第二OS发送所述跨系统服务请求的过程中确定所述第二OS处于故障状态，所述方法还包括：所述第二线程在所述存储介质中存储所述服务请求关联的上下文信息后休眠。
结合第二方面，在一种可能的实现方式中，若所述第二线程休眠时所述第二OS从故障状态恢复为非故障状态，所述方法还包括：所述第一处理节点从所述存储介质中读取所述跨系统服务请求关联的上下文信息，并唤醒所述第二线程；所述第二线程基于所述跨系统服务请求关联的上下文信息重新向所述第二OS发送跨系统服务请求。
结合第二方面，在一种可能的实现方式中，所述第一OS上还运行有第二APP，所述第一OS获取所述第二OS的状态信息，包括：所述第二APP周期性地发起跨系统调用请求；所述第一OS响应于所述跨系统调用请求向所述第二OS发送跨系统服务请求，并根据所述第二OS对所述跨系统服务请求的应答信息获取所述第二OS的状态信息。
结合第二方面，在一种可能的实现方式中，所述第一APP运行时还通过调用所述第一OS提供第二服务，其中，所述第一APP包括自动驾驶相关的至少一个APP，所述至少一个APP用于提供以下的至少一种服务：感知服务、融合处理服务或者规控服务；所述第二服务包括所述自动驾驶相关APP涉及的调度服务、进程管理服务或者内存管理服务中的至少一种，所述第一服务包括所述自动驾驶相关APP涉及的文件管理、中断管理或者通信管理中的至少一种。
第三方面，本申请提供了一种跨系统调用请求，应用于第二操作系统OS，所述第二操作系统部署在第二处理器，所述第二处理器设置在第二芯片上，所述方法可以包括：所述第二OS接收来自第一OS的跨系统服务请求，所述第一OS部署在第一处理器，所述第一处理器设置在第一芯片上，所述第一OS上运行有第一APP，所述服务请求为所述第一OS响应于所述第一APP发起的跨系统调用请求发送的；所述第二OS从多个线程中为所述跨系统服务请求分配可用的第一线程，所述第一线程用于对所述跨系统服务请求进行处理。
结合第三方面，在一种可能的实现方式中，所述第一芯片和所述第二芯片之间基于网络通信，所述第二OS接收来自第一OS的跨系统服务请求，包括：所述第二OS通过所述网络接收来自第一OS的跨系统服务请求，所述跨系统服务请求中包括所述服务标识和所述第一服务关联的跨系统调用参数。
结合第三方面，在一种可能的实现方式中，所述方法还包括：所述第二OS获取所述第一APP对实现所述第一服务的线程的需求信息，并根据所述需求信息释放所述多个线程中的至少一个线程，或者，根据所述需求信息为所述多个线程新建至少一个线程。
第四方面，本申请提供了一种通信装置，所述通信装置包括：通信接口，用于与其他装置进行通信；处理器，与所述通信接口耦合，使得所述通信装置执行如上述第一方面以及第一方面任一实现方式所述的方法，或者执行如上第二方面以及第二方面任一可能实现方式所述的方法，或者执行如上第三方面以及第三方面任一可能实现方式所述的方法。
第五方面，本申请提供了一种芯片系统，包括至少一个处理器和接口电路，所述处理器用于通过所述接口电路执行指令和/或数据的交互，使得所述芯片系统执行如上述第一方面以及第一方面任一实现方式所述的方法，或者执行如上第二方面以及第二方面任一可能实现方式所述的方法，或者执行如上第三方面以及第三方面任一可能实现方式所述的方法。
第六方面，本申请提供了一种车辆，包括计算节点，所述计算节点用于实现如上述第一方面以及第一方面任一实现方式所述的方法，或者实现如上第二方面以及第二方面任一可能实现方式所述的方法，或者实现如上第三方面以及第三方面任一可能实现方式所述的方法。
第七方面，本申请提供了一种计算机可读存储介质，包括程序或指令，当所述程序或指令被执行时，如上述第一方面以及第一方面任一实现方式所述的方法，或者执行如上第二方面以及第二方面任一可能实现方式所述的方法，或者执行如上第三方面以及第三方面任一可能实现方式所述的方法。
第八方面，本申请提供了一种计算机程序产品，当计算机读取并执行所述计算机程序产品时，使得计算机执行如上述第一方面以及第一方面任一实现方式所述的方法，或者执行如上第二方面以及第二方面任一可能实现方式所述的方法，或者执行如上第三方面以及第三方面任一可能实现方式所述的方法。
第九方面，本申请实施例提供了一种终端设备，包括用于实现如上述第一方面以及第一方面任一可能设计所述的方法的单元，或者实现如上述第二方面以及第二方面任一可能设计所述的方法的单元。示例地，该终端设备包括但不限于：智能运输设备(诸如汽车、轮船、无人机、火车、货车等)、智能制造设备(诸如机器人、工业设备、智能物流、智能工厂等)、智能终端(手机、计算机、平板电脑、掌上电脑、台式机、耳机、音响、穿戴设备、车载设备等)。
本申请实施例在上述各方面提供的实现的基础上，还可以进行进一步组合以提供更多实现。
上述第二方面至第九方面中任一方面中的任一可能实现方式可以达到的技术效果，可以相应参照上述第一方面至第二方面中任一方面中的任一可能实现方式可以达到的技术效果描述，重复之处不予论述。
附图说明
图1示出了使用虚拟机实现多系统共存的原理示意图；
图2示出了一种基于宏内核的操作系统的设计架构示意图；
图3示出了一种基于微内核的操作系统的设计架构示意图；
图4示出了基于QNX等嵌入式OS方案的计算平台的架构示意图；
图5示出了基于Linux内核方案进行开发的计算平台的架构示意图；
图6示出了基于Linux内核方案进行开发的计算平台中的代理机制的原理示意图；
图7示出了本申请实施例的系统架构示意图；
图8示出了本申请实施例的系统调用方法的流程示意图；
图9示出了本申请实施例的结合故障自愈机制的系统调用方法的流程示意图；
图10-图11示出了本申请实施例的不同故障检测方法的流程示意图；
图12示出了本申请实施例的故障后自愈的流程示意图；
图13示出了本申请实施例的通信装置的示意图；
图14示出了本申请实施例的通信装置的示意图；
图15示出了本申请实施例的通信装置的示意图。
具体实施方式
为了便于理解本申请实施例的技术方案，下面先对涉及的部分用语进行说明。
1、使用虚拟机实现多系统共存：
虚拟机技术是一种通过软件模拟硬件的方法，将一台计算机分割成多个独立的虚拟计算环境，这些虚拟计算环境可以运行不同的操作系统(operating system，OS)，就像运行在真实的计算机上一样。
虚拟化管理程序(Hypervisor)，又称虚拟机监视器(virtual machine monitor，VMM)，是用来建立与执行虚拟机器的软件、固件或硬件。
被Hypervisor用来执行一个或多个虚拟机器的电脑称为主体机器(host machine)，这些虚拟机器则称为客体机器(guest machine)。hypervisor提供虚拟的作业平台来执行客体操作系统(guest OS)，负责管理其他客体操作系统的执行阶段。这些客体操作系统，共同分享虚拟化后的硬件资源。如图1所示，基于虚拟化管理程序可以分别执行虚拟机1和虚拟机2，虚拟机1中可以包括操作系统1的内核，该操作系统1的内核上可以运行应用1，虚拟机2中可以包括操作系统2的内核，该操作系统2的内核上可以运行应用2。
2、异常等级(exception level，EL)：
在先进精简指令集机器(advanced RISC machines，ARM)处理器中，异常分为四个级别：EL0、EL1、EL2、EL3。其中，EL0是用户级别，或者说非特权模式，用于运行应用程序(application，APP)，其他资源访问受限(权限不够)。EL1是内核级别，或者说特权模式，用于操作系统内核的运行，可以访问系统的所有资源。EL2和EL3是虚拟化扩展级别，EL2用于运行虚拟化管理程序；EL3用于运行安全世界中的管理程序，安全模式(secure monitor)。
3、用户态和内核态：
在操作系统中，处理器允许模式通常只有EL0和EL1，也就是常说的用户态(对应EL0)和内核态(对应EL1)。
内核态和用户态是操作系统中两种不同的运行模式，两者的主要区别在于权限和可执行的操作。
(1)内核态：
内核态是操作系统运行的核心区域，控制着计算机的硬件资源，并为上层应用程序提供运行环境。
在内核态下，中央处理器(central processing unit，CPU)可以执行所有指令集，并访问所有硬件资源。这种模式下操作的权限最高，主要用于操作系统内核的运行和管理。
用户态下，CPU只能执行经过特权化处理的指令集的一部分，且无法直接访问硬件资源。在这种模式下，操作权限相对较低，主要用于运行用户自己的程序。
(2)用户态：
用户态是应用程序活动空间的体现，应用程序通过系统调用等方式请求和使用操作系统提供的服务。
在用户态下，进程不允许执行特权指令，如停止处理器、改变模式位或发起IO操作。用户态程序的数据和指令都在自己的虚拟地址空间内运行。
4、模式切换：
用户态和内核态之间的切换称为模式切换。
用户态和内核态之间的切换可以通过多种方式发生，包括但不限于：
(1)系统调用(system calls)：用户态进程主动发起的请求，用于申请使用操作系统提供的服务程序完成工作。
(2)异常：当CPU在执行用户态下的程序时发生的未预料的异常事件，会导致进程切换到处理该异常的内核相关程序中。
(3)外围设备中断：当外部设备完成操作后发出的中断信号，也会引起进程从用户态切换到内核态以响应该中断。
5、进程(process)和线程(thread)：
在计算机中，进程是指一个正在运行的程序实例。当一个程序启动时，操作系统会为该程序创建一个进程，进程是计算机中资源分配的基本单位，包含程序执行所需的代码、数据和堆栈等信息。一个进程可以拥有多个线程，每个线程可以独立地执行代码，但它们共享进程的内存和其他资源。每个进程都有一个唯一的进程标识(identity，ID)，用来标识该进程。进程可以与其他进程进行通信，例如通过关联、共享内存、套接字(socket)等方式交换数据。
线程是操作系统能够进行运算调度的最小单元，是进程中的一个执行流程。一个进程可以包含多个线程，每个线程是进程中的一个执行单元，可以独立地执行特定的任务。一个程序中，多线程可以同时执行不同的任务，从而实现并发执行。与进程相比，线程更加轻量级，由于线程可以共享进程的内存和其他资源，使得线程之间的通信和数据共享更加容易和高效。线程的实现方式可以有多重，例如用户级线程、内核级线程、轻量级进程等。开发人员可以根据需求和目标选择合适的线程模型。
6、用户空间(user space)和内核空间(kernel space)：
每个进程通常有两个栈，分别位于用户空间和内核空间。在用户空间时，CPU使用的堆栈指针寄存器的内容指向用户堆栈地址。在内核空间时，则指向内核栈空间地址。
进程处于用户态时不能访问内核空间，也不能直接进行调用内核的函数，当需要调用时将进程切换到内核态。用户态可以通过系统调用、库函数、Shell脚本来访问内核态资源。这样的设计是为了确保安全和稳定性的需求，防止用户程序随意访问操作系统资源或执行危险指令。
7、上下文(context)：
在计算机中，上下文通常指的是程序或进程执行时的环境，包括所有相关的变量和数据。其中，对于进程来说，上下文包括寄存器变量、进程打开的文件、内存信息等；对于线程来说，上下文包括寄存器、线程堆栈等；对于CPU来说，上下文包括操作数寄存器、栈寄存器、状态寄存器等。上下文包含了程序执行所需的所有信息，对于程序的正确执行非常重要。在程序执行过程中，如果上下文被破坏或丢失，可能会导致程序崩溃或异常。
在计算机编程中，上下文涵盖了程序执行的环境和状态信息，可以帮助程序管理状态、控制流以及执行过程。例如，上下文切换(context Switch)是操作系统在多任务环境中管理进程和线程时发生的一种事件，涉及保存当前任务的状态(即上下文)以便稍后恢复，并将控制权转移给下一个任务。这个过程包括将当前任务的寄存器内容和程序计数器保存在进程控制块中，然后恢复下一个任务的上下文，并从下一个任务的程序计数器所指向的位置继续执行。
8、用户级线程(user level thread)和内核级线程(kernel level thread)：
进程和线程由操作系统负责管理和调度，其状态随时都可能转变。一般会有一个主线程随着进程的创建一起出现。CPU将它们根据权限划为两个类型：用户态线程和内核态线程。
内核态线程或称内核级线程，内核级线程拥有较高的权限，对于某些操作不需要通过系统调用。内核态线程运行在内核中，由内核来控制。
用户态线程又称用户级线程，在用户空间中被创建并且内核并不会知道它的存在，创建与销毁不需要经过系统调用，可以由自己维护而不是内核来管理。相对的管理成本更小。但是它在线程间通信的成本会更高，因为需要通过系统调用才能用到通信需要的I/O。由用户空间程序管理，与内核协作需要进行I/O的时候，需要频繁切换用户态和内核态。由于不归内核管理，当一个进程的某个用户态线程中阻塞时内核无法及时处理问题。
9、共享内存：
共享内存(shared memory)是进程间通信中最简单的方式之一，让多个进程访问同一内存，当一个进程改变了这块内存的内容，其他进程也能察觉。这既简单又高效，但多个参与共享的进程不应该同时读写。
10、宏内核和微内核：
(1)宏内核(monolithic kernel)：
宏内核也可以称为单内核(Monolithic Kernel)，是一种操作系统内核的设计架构，其特点是将大部分或全部的系统功能直接实现在内核中，例如除了最基本的进程、线程管理、内存管理外，文件系统、设备驱动、网络系统等都实现在内核里。
如图2所示，Linux操作系统是一个开放源代码的多用户、多任务操作系统，Linux宏内核包括多个基础模块，例如进程管理模块(或者称为进程调度(process scheduler)模块)、内存管理(memory manager)模块、文件系统模块、设备驱动模块、网络系统模块等，依托于CPU、RAM、硬盘、CD、终端设备、网络适配器等硬件，采用软硬件结合的方式，Linux内核的各个基础模块可以为运行在用户空间的应用工具提供多任务的调度功能、虚拟内存管理功能、文件目录功能、终端访问功能和网络功能等。
宏内核架构允许操作系统资源直接在内部实现，提供了高效的性能和高度的集成度，减少了进程间通信可能导致的性能损失，从而提高系统的整体执行速度，同时具有较高的执行效率和良好的操作系统资源管理能力。宏内核的内核代码编译后形成的二进制文件运行在一个大内核地址空间中，可以直接访问和使用内核代码。
宏内核架构最大的挑战之一就是内核代码量的庞大，这可能导致内核变得难以理解和维护。此外，由于所有的组件都在内核中实现，如果某个组件出现问题，可能会影响到整个系统的稳定性。但由于宏内核提供了高效的性能和高度的集成度，仍被许多操作系统采用。
(2)微内核(micro kernel)：
微内核又称为微核心，是内核的一种精简形式，微内核架构将系统服务层被分离出来变成可以根据需求加入的选件，内核中只有最基本的调度，内存管理，驱动、文件系统等都是用户态的守护进程实现的，微内核中功能被划分成独立的过程，过程间通过进程间通信(inter-process communication，IPC)进行通信。微内核架构中，模块化程度高，可以提供更好的可扩展性，同时由于一个服务失效不会影响另一个服务，可以提供更加有效的应用环境。
如图3所示，QNX Neutrino实时操作系统(real time operating system，RTOS)是一个分布式、嵌入式、可扩展、遵从可移植操作系统接口(portable operating systeminterface，POSIX)规范的类Unix实时操作系统，在硬件层之上，QNX提供了板级支持包(board support package，BSP)、RTOS微内核、软件中间层以及支撑应用的增强服务层。RTOS微内核仅提供4种服务，分别为：进程调度、进程间通信、底层网络通信和中断处理。驱动程序、协议栈、文件系统、应用程序等都在微内核之外内存受保护的安全的用户空间内运行，组件之间能避免相互影响，在遇到故障时也能重启。
11、电子电气(electrical and electronic，E/E)架构：
汽车E/E架构是集合了汽车的电子电气系统原理设计、中央电器盒设计、连接器设计、电子电气分配系统等设计为一体的整车电子电气解决方案。
随着汽车功能需求的增加和技术的飞速进步，整个汽车行业开始发生颠覆性的变革。近几年，随着汽车行业走向智能化，传统的分布式E/E架构逐渐向中央集成E/E架构演进，同时也对整车设计提出了更高的要求。例如，新能源汽车(例如插电式混合动力汽车和纯电动汽车)的三电系统增加了汽车E/E架构的复杂程度。或者例如，应用了智能座舱和自动驾驶技术的车辆，存在基于空中下载技术(over-the-Air technology，OTA)的更新需求、大量数据处理和信号传输的需求，对车载智能计算平台的算力和车辆安全设计的要求更高。
12、车载智能计算平台(下文中也可以简称为计算平台)：
自动驾驶车辆围绕感知、决策和执行三大环节构建软硬件系统，车载智能计算平台是自动驾驶车辆的“大脑”，主要负责完成感知环节的识别融合任务以及整个决策环节，需要处理海量数据和进行复杂的逻辑运算。
为满足高算力需求，目前车载智能计算平台集成多个系统级芯片(system on chip，SoC)，每个SoC集成多类计算单元(如CPU、GPU、FPGA、ASIC等)。同时，车载智能计算平台还需要高效的软件架构支持应用开发。其软件架构高度分层化和模块化，主要分为系统软件(虚拟机、操作系统和中间件)、功能软件和应用程序三层。相较于传统零部件，车载智能计算平台涉及各类芯片和软件，供应商来自不同领域，供应生态多样。
随着E/E架构演进，计算平台被重新定义，其中操作系统和应用软件也需要被重新定义。由于智能驾驶软件算法迭代迅速，依赖大量的三方库，整个软件栈功能极为复杂，对基础软件OS带来极大的挑战。因此，业界逐步开始探索在车载智能计算平台基于虚拟机构筑双Guest OS系统，例如通过虚拟化技术实现同时运行两个OS的方案。此类系统通常是指通过虚拟化技术运行在同一硬件平台，共享底层硬件资源，提供多分区服务能力。其中，这两个OS可以分别称为通用OS和功能安全OS，通用OS主要满足丰富生态的需求，保证系统的功能完备性；功能安全OS主要提供精确的实时控制、确定性调度和高性能执行环境，两者相互协作共同提供满足诉求的系统。
然而，不同的原始设备制造商(original equipment manufacturer，OEM)提供的计算平台中应用基于虚拟机构筑双Guest OS系统时，还存在各自的不足。
(1)传统OEM提供的基于QNX等嵌入式OS方案的计算平台：
如图4所示，在智能汽车领域，通过Hypervisor层虚拟化后可以提供多Guest OS的运行能力，提供基于QNX等嵌入式OS方案的计算平台，包括基于Linux内核(kernel)的通用OS和基于QNX微内核的安全OS。其中，在通用OS侧，基于Linux内核提供标准系统服务，包括网关、管理、地图、云服务等。在安全OS侧，基于QNX微内核提供QNX系统服务，例如符合汽车开放系统架构(AUTomotive Open System Architecture，AUTOSAR)的基础软件框架以及自动驾驶相关应用，自动驾驶相关应用可以为车辆提供感知、融合、规控等服务。
尽管基于QNX等嵌入式OS方案的多组件已支持最高的汽车安全完整性等级(automotive safety integration level，ASIL)-D认证，在安全领域具备优势，但是受限于QNX的非开源特性，导致基于QNX等嵌入式OS方案的生态支持不足，开发不够灵活，难以满足复杂的智能驾驶业务的开发调试和运行需求。同时，QNX驱动作为进程，其驱动程序移植需要定制重写，将会导致车企绑定多种授权模式和商业模式，整体成本较高。并且，受限于QNX所采用的微内核架构，部分OS关键性能会受进程间通信(IPC)影响而降低。
因此，基于QNX等嵌入式OS方案的计算平台难以满足安全OS中的自动驾驶相关应用的开发对丰富生态、快速迭代的诉求。
(2)新势力OEM提供的基于Linux内核方案进行开发的计算平台：
如图5所示，在智能汽车领域，通过Hypervisor层虚拟化后可以提供多GuestOS的运行能力，提供基于Linux内核方案进行开发的计算平台。该计算平台是一种基于Linux内核方案是一种增加实时、安全内核的方案，通过Hypervisor层隔离出通用OS和安全OS，通用OS完成管理以及生态算法相关的应用程序的执行；安全OS提供实时性、高性能和安全算法应用程序的执行。但是，安全OS不具备独立运行能力，安全OS上的APP(简称为安全APP)的运行强依赖通用OS内核功能，通过代理机制，使Linux内核作为服务分区，给安全OS侧的APP提供系统调用服务/缺页异常服务/维测代理服务等，以提供实时性、高性能和安全算法应用程序执行。
如图6所示，该方案中，由Linux内核启动安全APP，Linux内核将安全APP作为一个普通的Linux APP正常启动。例如步骤①中，由Linux进程/线程启动安全APP，以使安全APP陷入内核态。但是，Linux内核完成安全APP内核态初始化、并准备进入安全APP执行时，执行流会被底层Hypervisor层截获，例如Hypervisor层通过中断机制和共享内存截获线程上下文。所截获的线程上下文在步骤②中搬移到安全OS上的安全APP执行。当安全APP运行过程中，例如在步骤③触发系统调用服务/缺页异常服务/维测代理服务。在步骤④，安全OS的内核所设置的代理机制，会将相关服务请求重定向到Linux内核处理，也即代理请求。该代理请求中需要携带安全OS侧的相关线程上下文，以描述线程的执行状态。Linux内核等待处理代理请求。在Linux内核中，安全APP内核态一直阻塞等待，一旦收到安全OS发送的代理请求，则基于该代理请求中携带的相关线程上下文运行特定的线程，调用linux内核相应的函数对该代理请求进行处理，并将处理结果返回该安全OS内核。
基于上述代理机制，通用OS的线程与安全OS的线程基于线程上下文强绑定，以1:1的强绑定关系，随着业务增多，系统底噪会线性增长，并且会给通用OS的维测统计带来较大的压力。并且，整体执行路径较长，会导致系统性能降低。而安全OS对通用OS的强依赖，会使得安全OS在通用OS故障后无法工作，难以满足高功能安全要求。
针对上述问题，本申请提供了一种系统调用方法和装置，用于在车辆的计算平台实现多系统共存，同时使得安全OS能够高效地复用通用OS的生态，尽可能地保障整个计算节点的系统性能。在一种可选的实施方式中，该方案还可以使得通用OS与功能安全OS相互协作，以在通用OS故障后仍可使得安全OS自愈，以较低的成本满足高功能安全的诉求。其中，方法和装置是基于同一技术构思的，由于方法及装置解决问题的原理相似，因此装置与方法的实施可以相互参见，重复之处不再赘述。并且，在本申请的各个实施例中，如果没有特殊说明以及逻辑冲突，各个实施例之间的术语和/或描述具有一致性、且可以相互引用，不同实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。
需要说明的是，本申请实施例中“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，可以表示：a,b,c,a和b,a和c,b和c,或a和b和c，其中a,b,c可以是单个，也可以是多个。
以及，除非有特别说明，本申请实施例提及“第一”、“第二”等序数词是用于对多个对象进行区分，不用于限定多个对象的优先级或者重要程度。例如，第一OS、第二OS，只是为了区分不同的OS，而不是表示这两个OS的优先级或者重要程度等的不同。
下面结合附图及实施例进行详细介绍。
图7示出了本申请实施例的系统架构示意图。
如图7所示，该架构中可以包括至少两个操作系统(operating system，OS)，例如表示为第一OS和第二OS，以及未示出的其它OS。
其中，该至少两个操作系统可以是部署在同一硬件平台上并采用前文述及的虚拟机技术分割得到的不同虚拟运行环境中，例如采用虚拟机技术将同一处理器分割为不同的虚拟运行环境后，在不同的运行环境上部署不同的操作系统，例如图7中的第一OS可以部署在一个处理器的第一虚拟运行环境中，第二OS可以部署在该处理器的第二虚拟运行环境中。
或者，该至少两个操作系统可以部署在多域芯片上。例如，芯片内部划分为不同的区域或者功能块，每个区域或者功能块可以成为一个域(domain)，不同的域可以具有不同的处理器核心、内存、I/O接口等资源配置，每个域负责不同的任务和功能，以实现不同的功能或者性能要求。该至少两个操作系统中的任一操作系统可以部署在一个域的处理器核心上，实现更高效、更安全的芯片运行。例如，图7中的第一OS可以称为功能安全域，部署在功能安全域的处理器核心上，第二OS称为通用域，部署在通用域的处理器核心上。
或者，该至少两个操作系统还可以部署在不同的芯片上。例如，图7中的第一OS可以部署在第一处理器上，该第一处理器设置在第一芯片上，第二OS可以部署在第二处理器上，该第二处理器设置在第二芯片上。
无论采用上述的哪一种部署方式，第一OS与第二OS之间均可构筑安全共享通道，运行在第一OS的第一APP既可以采用系统调用的方式申请使用第一OS提供的资源或服务，又可以通过跨OS系统调用的方式和该安全共享通道申请使用第二OS提供的资源或服务。该第一OS的内核可以包括多个功能节点(或称为功能模块)，该多个功能节点可以对第一APP发起的面向第一OS内核的系统调用请求进行处理。该第二OS的内核也可以包括多个功能节点(或称为功能模块)，该多个功能节点可以对第一APP发起的面向第二OS的跨OS系统(服务)调用请求进行处理。
为了便于区分，本申请实施例中可以将利用第二OS的系统资源提供的服务称为第一服务，将利用第一OS的系统资源提供的服务称为第二服务。将第一OS的内核中为第一APP提供相同OS系统调用服务的内核节点称为第二处理节点，将第一OS的内核中为第一APP提供跨OS系统调用服务的内核节点称为第一处理节点，该第一处理节点也可以称为跨OS系统调用服务的客户端，用于响应于来自第一APP的系统跨OS系统调用请求，通过第一OS与第二OS之间的安全共享通道向第二OS发送服务请求，以申请使用第二OS提供的资源或服务。第二OS的内核中可以包括第三处理节点，该第三处理节点也可以称为跨OS系统调用服务的服务端，用于接收来自第一OS的服务请求，并为从第二OS的多个线程中为该服务请求分配可用的第一线程，以使该第一线程对该服务请求进行处理，即为第一OS侧的APP提供跨OS系统调用服务。
在具体实施时，第一OS的内核中还可以包括服务路由节点，用户态的第一APP发起系统调用请求后陷入内核态，在内核态下，第一OS的内核中的服务路由节点会分析来自第一APP的系统调用请求是面向第一OS的内核发起的，还是面向第二OS发起的。如果该系统调用请求是面向第一OS的内核发起的，服务路由节点会将该系统调用请求路由至第二处理节点，该第二处理节点可以利用第一OS的系统资源对该系统调用请求进行处理，以使第一APP实现相应的任务或者功能。如果该系统调用请求是面向第二OS发起的，服务路由节点会将该系统调用请求路由至第一处理节点，第一处理节点可以根据该系统调用请求中携带的信息、以及第一OS与第二OS之间的安全共享通道向第二OS发送相应的服务请求，以向第二OS申请使用第二OS提供的资源或服务。
本申请实施例中，可以通过不同的方式实现第一OS与第二OS之间的安全共享通道。例如，第一OS与第二OS之间可以通过网络通信技术建立网络通信通道作为该安全共享通道，第一处理节点可以通过该网络通信通道向第二OS发送服务请求，该服务请求中可以包括第一服务的服务标识和第一服务关联的系统调用参数，以便在第二OS侧所分配的第一线程可以根据该服务标识和系统调用参数，利用该第二OS侧的系统资源，对该服务请求进行处理，以实现第一OS侧的第一APP的任务或功能。或者例如，第一OS与第二OS之间可以通过共享内存和中断机制实现该安全共享通道，该安全共享通道中还可以设置有无状态系统服务请求模块(图中未示出)，第一处理节点可以响应于来自第一APP的系统调用请求向该无状态系统服务请求模块发送第一服务关联的服务标识和第一服务关联的系统调用参数，该无状态系统服务请求模块可以在共享内存中存储该系统调用参数，以及构造服务请求，该服务请求中包括服务标识(或称为管理信息/控制信息)和系统调用参数在共享内存中的存储地址。相应地，第一线程可以基于服务请求中携带的地址信息，从共享内存中读取相应的系统调用参数，以基于该服务标识和系统调用参数对该服务请求进行处理。
第二OS可以包括多个线程(例如表示为线程1、线程2、…线程n，n为大于或等于2的整数)，该多个线程可以是内核线程(轻量级线程)，任一线程空闲时可被调度分配给来自第一OS的服务请求，以对该服务请求进行处理，从而使第一APP利用第二OS的系统资源实现相应的任务或者功能。下文中将结合方法流程图进行详细介绍，在此暂不赘述。
应理解，此处仅是以系统调用方式为例对第一APP的任务或者功能的实现方式的介绍而非任何限定。在其他实施例中，第一APP的软件开发工具包(software development kit，SDK)中还可以集成三方库(外部开源库)的访问接口，第一APP运行时，还可以通过该访问接口访问三方库，以获得更多的资源或者实现更多的功能。或者，第二OS的多个线程还可以包括运行在用户态的线程，当第一APP发起面向第二OS的系统调用请求时，也可由第二OS的运行在用户态的空闲线程对相应的服务请求进行处理，本申请实施例对第一APP的服务提供方式不做限定。
由此，通过上述方案，来自第一OS的服务请求只包含第一服务关联的服务标识和系统调用参数(或者该系统调用参数在共享内存中的存储地址)，而不包含完整的线程上下文信息，是一种无状态的跨OS系统调用请求，能够将该服务请求与线程状态解耦，使得在第二OS侧能够实时地为该服务请求分配可用的空闲线程，这不同于前文介绍的基于代理机制中需要基于线程上下文将跨OS系统的服务请求与特定线程进行1:1强绑定的方案，能够降低系统底噪，提升整个系统的性能。该方案同样能够实现改变对第二OS的线程管理方式，例如转变为以线程池的方式管理第二OS的多个线程，支持动态地对第二OS的线程进行扩容或者缩容，以满足系统需求，同时降低第二OS的系统资源的开销。
此外，由于第一APP的部分任务或功能的实现需要依赖于第二OS的线程，如果第二OS故障，致使第二OS的线程无法接收到来自第一OS的服务请求，将会影响到第一APP的功能或业务的持续运行。因此为了保障系统的健壮性和鲁棒性，一种实施方式是，在第一OS中设置故障自愈节点，并在第一APP和第一处理节点设置故障自愈机制，以使得第一APP面向第二OS发起系统调用请求之前或者面向第二OS发起系统调用请求的过程中，检测第二OS是否故障，并在第二OS故障时或者故障恢复后，及时地启动故障自愈机制，以保障第一APP的任务或功能恢复执行。
例如，该故障自愈节点可以是基于心跳检测机制，实时地或者周期性地检测第二OS的运行状态，并将该第二OS的状态信息告知给第一处理节点和/或第一APP，该状态信息可以包括第二OS所处的故障状态或者非故障状态。或者，也可以在该第二OS侧设置“临终遗言”功能，使得第二OS故障时，启动该“临终遗言”功能而主动向第一OS侧的故障自愈节点告知自身处于故障状态。本申请实施例对第二OS的故障检测机制的具体实现方式不做限定。
在一个示例中，若第一处理节点在第一APP发起面向第二OS的系统调用请求之前确定该第二OS处于故障状态，该第一处理节点可以在保存该系统调用请求关联的上下文信息后休眠，以暂停对第二OS的系统调用，以免该系统调用请求无响应。同时，若第一处理节点休眠时该第二OS从故障状态恢复为非故障状态，则第一OS需要重新获取系统调用请求关联的上下文信息并唤醒该第一处理节点，该第一APP可以根据该系统调用请求关联的上下文信息重新发起该系统调用请求，第一处理节点可以重新响应于该系统调用请求向第二OS发送服务请求。由于第二OS已经恢复为非故障状态，因此该服务请求可以被第二OS侧重新接收和处理，则不影响第一OS侧的任务或者功能的实现。
在另一个示例中，若该第一APP的线程(或者进程)在向第二OS发送服务请求的过程中确定第二OS处于故障状态，该第一APP的线程(或者进程)在保存该服务请求关联的上下文信息后休眠，以免该服务请求无响应。同时，若该第二线程休眠时所述第二OS从故障状态恢复为非故障状态，则第一处理节点可以重新获取服务请求关联的上下文信息并唤醒第一APP的线程(或进程)，该第一APP的线程(或进程)可以基于服务请求关联的上下文信息重新向第二OS发送服务请求。由于第二OS已经恢复为非故障状态，因此该服务请求可以被第二OS侧重新接收和处理，则不影响第一OS侧的任务或者功能的实现。
若该第一APP的线程(或者进程)在向第二OS发送服务请求之后确定第二OS处于故障状态，则该服务请求可能已被第二OS的线程接收和处理，即使第二OS侧故障后恢复，该服务请求认可被恢复处理，不影响第一OS侧的任务或者功能的持续运行，则无需在第一OS侧执行故障自愈机制。
在另一种实施方式中，还可以在第一OS上安装和运行第二APP，该第二APP可以用于触发第一OS内核中的故障自愈节点实时地或者周期性地检测第二OS的运行状态。本申请实施例对该故障检测机制的实现方式不做限定。
由此，上述方案中，在第一OS侧独立实现第一APP的任务或功能的基础上，通过上述故障自愈机制，即使第二OS侧发生故障，第一OS侧依然能够独立运行若干分钟的安全任务，并在第二OS的故障恢复后，使得第一OS侧面向第二OS的系统调用能够自愈运行。作为示例，上述第二OS可以采用生态能力较佳的Linux系统，以使得整个通信系统尽可能满足功能安全、性能、生态的最佳状态。
为了便于理解，下面以图7中的第一OS和第二OS通过虚拟机技术部署在车辆的计算节点为例，对本申请实施例的系统调用方法进行介绍。其中，该第一OS还可以称为功能安全OS，第一OS上可以运行有第一APP，该第一APP可以包括自动驾驶相关的APP，第一OS提供的第二服务可以包括自动驾驶相关APP涉及的调度服务、进程管理服务或者内存管理服务中的至少一种。第二OS还可以称为通用OS，该通用OS提供的第一服务可以包括自动驾驶相关APP涉及的文件管理、中断管理或者通信管理中的至少一种。
图8示出了本申请实施例的系统调用方法的流程示意图。如图8所示，该方法可以包括以下步骤：
S810：第一APP发起第一系统调用请求。
本申请实施例中，无论是第一OS还是第二OS都可以有很多系统资源，这些资源并不能被APP随意访问，因此OS可以提供通路给APP使用，例如提供系统调用(函数)接口和系统调用号，不同的系统调用都对应于唯一的系统调用号。在第一OS侧，可以预设不同的系统调用号分别与第一服务和第二服务的邦定关系，例如可以将读(read)/写(write)接口对应的系统服务调用号设置为第二服务绑定的系统调用号，用于提供对内存的读/写管理服务。或者例如，可以将挂载(mount)接口对应的系统服务调用号设置为第一服务绑定的系统调用号，用于提供文件管理服务。
若S810中，第一APP是面向第二OS发起该第一系统调用请求，则该第一系统调用请求中可以包括第一服务的服务标识，该服务标识可以是第一服务绑定的系统调用号。若该第一APP是面向第一OS发起该第一系统调用请求，则该第一系统调用请求中可以包括第二服务的服务标识，该服务标识可以是第二服务绑定的系统调用号。在一种可选的实施方式中，若某些服务既可以由第一OS提供也可以由第二OS提供，则该第一系统调用请求中包括的服务标识可以实现为系统调用号和标号的组合，该标号可以指示由第一OS提供还是由第二OS提供。基于该服务标识，第一OS内核中的服务路由节点可以知悉将该第一系统服务请求路由至第一处理节点还是第二处理节点。
应理解，第一APP对于第二服务的调用为同OS的系统调用，该系统调用过程的具体实现可以参见相关技术，在此不再赘述，下文中将主要介绍第一APP对于第二OS提供的第一服务的系统调用流程。
S820：第一OS根据服务标识向第二OS发送服务请求。
本申请实施例中，如图7所示，第一OS的内核中可以包括服务路由节点，该服务路由节点可以根据第一系统服务请求中携带的服务标识来识别该第一系统服务请求具体是面向第一OS提供的第二服务发起的还是面向第二OS提供的第一服务发起的，若是面向第二OS提供的第一服务发起的，则该服务路由节点将该第一系统服务请求路由至第一OS的内核中的第一处理节点。实施S820时，可由该第一处理节点根据第一系统调用请求中携带的服务标识向第二OS发送服务请求。例如，第一处理节点通过第一OS与第二OS之间的网络通信通道向第二OS发送服务请求，该服务请求中包括第一APP请求调用的第一服务的服务标识和第一服务关联的系统调用参数，例如第一APP的线程标识、系统调用函数的入参等。第三处理节点可以接收该服务请求，并为该服务请求分配可用的第一线程。该第一线程运行时，可以根据第一服务的服务标识和第一服务关联的系统调用参数，并利用第二OS的系统资源对该服务请求进行处理。
一种可选的实施方式中，该第一系统调用请求中还可以包括第一服务关联的系统调用参数，例如第一APP的线程标识、系统调用函数的入参等。第一OS与第二OS之间的安全共享通道可以实现为两者之间的共享内存。在实施S820时，该第一OS还可以向该共享内存中申请第一内存空间，并在该第一内存空间中存储第一服务关联的系统调用参数，例如包括第一APP的线程标识、系统调用函数的入参等、不包含第一OS侧任务的上下文状态信息(包含各种状态寄存器)。共享内存中可以包括无状态系统服务请求模块，该无状态系统服务请求模块可以向第二OS发送服务请求，该服务请求中可以包括服务标识和第一地址，该第一地址为第一服务关联的系统调用参数在该第一内存空间中的存储地址。相应地，第二OS在接收到该服务请求之后，可以根据该第一地址从第一内存空间读取第一服务关联的系统调用参数，以便第二OS根据该系统调用参数对该服务请求进行处理。
S830：第二OS接收服务请求，并从多个线程中为服务请求分配可用的第一线程。
本申请实施例中，如图7所示，该多个线程可以是第二OS的内核线程，第二OS可以按顺序选择一个空闲的线程作为可用的第一线程分配(或称为“取出”或“摘下”，)给该服务请求。在一个示例中，具体可由第二OS的内核中的第三处理节点调度和管理多个内核线程。例如第二OS可以是在第三处理节点初始化时，创建服务线程池，该服务线程池中包括多个内核线程，可用于为第一OS侧提供跨系统调用服务。在接收到来自第一OS的服务请求时，第三处理节点可以为该服务请求分配可用的第一线程。例如图7中，若线程1被占用、线程2空闲，第三处理节点可以将线程2分配给该服务请求。
在一种可选的实施方式中，第二OS侧的内核服务线程池还支持动态扩容或者动态缩容。例如，第二OS中的第三处理节点可以获取第一APP对所述第一服务的线程的需求信息，并根据所述需求信息释放所述多个线程中的至少一个线程，或者，根据所述需求信息为所述多个线程新建至少一个线程。这样，通过释放第二OS内核中的富裕的服务线程的资源，以提高对第二OS的系统资源的使用率，或者为第一OS创建更多的服务线程，以满足第一OS侧的跨OS系统服务的需求。
S840：第一线程对服务请求进行处理。
例如，第一线程在第二OS上运行时，根据服务请求中携带的第一地址从第一内存空间中读取第一服务关联的系统调用参数，该系统调用参数中不涉及第一OS任务的上下文状态。第一线程无需感知第一OS任务的上下文状态，可以直接根据该系统调用参数对该服务请求进行处理。在处理完毕后，第一线程可以通过第一OS与第二OS之间的安全共享通道向第一处理节点反馈处理结果，并释放此过程所申请的资源。例如第一线程通过安全共享通道向第一处理节点发送返回值，即本次系统服务请求的处理结果，表示成功与否。第一处理节点会将该返回值返回给用户态的第一APP，至此完成一次跨OS的系统调用服务。
上述过程中，由于第一处理节点通过安全共享通道向第二OS提供的系统调用参数而不包含执行第一OS侧任务的进程/线程的上下文信息，因此第二OS侧的内核线程无需感知第一OS任务的上下文状态，也就无需与第一OS侧的线程进行1:1的强绑定，能够将第二OS侧的服务线程与第一OS侧的任务解耦，从而降低整个系统的底噪，提升系统性能。
此外，将第一APP发起第一系统调用请求的线程在第一OS侧的执行过程称为执行流，本申请实施例的故障自愈机制的检查点可以是该执行流中的控制节点，该检查点处可以通过检查第二OS的状态来控制后续执行步骤。
在一个示例中，检查点可以设置在第一处理节点。如图9所示，结合本申请实施例的故障自愈机制，该系统调用方法可以包括以下步骤：
S901：第一APP发起第一系统调用请求，以请求使用跨OS系统服务。
S902：第一OS内核中的服务路由节点判断该第一系统调用请求是否是面向第二OS发起的？若是，则进入S903，若否则进入S909。
S903：服务路由节点将第一系统调用请求路由至第一OS内核中的第一处理节点。
S904：设置在第一处理节点的检查点获取第二OS的状态信息，以判断该第二OS是否处于故障状态。若是，则进入905，通过实施故障自愈机制，以保存服务请求关联的上下文信息，以便在第二OS从故障状态恢复至非故障状态时，根据所保存的服务请求关联的上下文信息重新向第二OS发送服务请求。若否，则进入S906。
S905：实施故障自愈机制，以保存服务请求关联的上下文信息，以便在第二OS从故障状态恢复至非故障状态时，第一处理节点可以根据所保存的服务请求关联的上下文信息重新向第二OS发送服务请求。恢复后，还可以返回S903，以在第一处理节点采用实时或者周期性的方式，来检测第二OS是否故障。
其中，第一OS的内核中可以包括第一APP关联的第二线程，该第二线程可以是第一APP的运行在内核态的用于实现第一APP的任务的线程，第一处理节点可以用于管理该第二线程，以向第二OS进行系统调用。在实施S904时，具体可以是第二线程确定第二OS是否处于故障状态。若是，则在实施S905时，由第二线程保存服务请求关联的上下文信息后休眠。例如，第二线程可以在共享内存(例如第一内存空间)中存储所述服务请求关联的上下文信息后休眠。之后当第二OS从故障状态恢复至非故障状态时，第一处理节点可以从共享内存中读取服务请求关联的上下文信息，并唤醒第二线程。该第二线程可以基于服务请求关联的上下文信息重现向第二OS发送服务请求。
S906：第一处理节点通过安全共享通道中的无状态系统服务请求模块，向第二OS发送服务请求，以请求调用第二OS的系统服务。例如，第一处理节点可以向无状态系统服务请求模块告知所需调用的第一服务的服务标识，同时向共享内存申请第一内存空间，并在所述第一内存空间中存储所述第一服务关联的系统调用参数。无状态系统服务请求模块可以根据第一服务的服务标识和第一地址，向第二OS发送服务请求，该服务请求中包括服务标识和第一地址，第一地址为第一服务关联的系统调用参数在所述第一内存空间中的存储地址。
S907：第二OS内核中的第三处理节点接收服务请求，并从多个内核线程中为该服务请求分配可用的第一线程。第一线程运行时，根据该服务请求中携带的第一地址，从共享内存中读取第一服务关联的系统调用参数，并根据该系统调用参数对服务请求进行处理。
S908：在处理完成后，第一线程通过安全共享通道向第一处理节点发送处理结果，并释放相关服务资源。例如发送返回值，用于表示成功与否。相关服务资源可以包括第一线程对应的运行资源，还可以包括第一线程对服务请求进行处理时所使用的第二OS的系统资源，本申请实施例对此不做限定。相应地，第一处理节点还可以向用户态的第一APP发送处理结果，即完成本次跨OS系统调用服务的处理。
S909：第二OS内核中的第二处理节点响应于来自第一APP的同OS系统调用请求，使用第一OS的系统资源为第一APP提供系统服务。
由此，上述方法通过在第一处理节点所管理的内核态线程响应于第一系统调用请求向第二OS发送服务请求的过程中检查第二OS的状态，以在第二OS处于故障状态时及时保存服务请求关联的上下文信息和控制第二线程休眠，以便在第二OS的故障恢复后，自主唤醒第二线程来重新向第二OS发送服务请求，以减少以第二OS故障而导致服务请求无法被第二OS接收和处理的情形，以及恢复使用系统服务的第一APP继续运行，提升数据面OS的健壮性和安全性。
在另一个示例中，第二OS的故障可能发生在第一APP的跨OS系统调用服务的执行流的任意时刻，本申请实施例中，还可以针对第二OS故障的不同发生时机执行不同的处理流程。
如图10所示，可以在用户态的第一APP设置检查点。例如，在第一OS中，可以启动第二APP作为检测第二OS的状态的常驻进程，该第二APP可以周期性地向第二OS发起第二系统调用请求，第一OS中的第一处理节点可以通过第三线程，响应于该第二系统调用请求向第二OS发送服务请求，并根据第二OS对该服务请求的应答信息获取第二OS的状态信息。例如，该应答信息可以包括返回值和时间戳，该返回值可以表示第二OS已成功接收到该服务请求。第一处理节点可以将第二OS对该服务请求的应答信息告知给第二APP。第二APP可以判断是否接收到预期的返回结果，例如在固定时间间隔内是否接收到预期的返回结果，或者是在多次固定时间间隔内是否接收到预期的返回结果。若是，则可以判定第二OS的状态无异常，即处于非故障状态。若否，则可以判定第二OS处于故障状态。
如图11所示，可以在内核态设置检查点。第一APP在发起跨OS系统调用请求之前可以通过与第二APP交互，来获取第二OS的状态信息，若在第一APP发起跨OS系统服务调用请求之前确定第二OS处于故障状态，则该第一APP可以指示第一处理节点在共享内存中存储所要发起的第一系统调用请求关联的上下文信息后休眠。第一处理节点所管理的第二线程，即第一APP的运行在内核态的第二线程，可以与第一OS内核的故障自愈模块交互，来获取第二OS的状态信息，若第一处理节点控制第二线程响应于第一系统调用请求向第二OS发送服务请求的过程中确定第二OS处于故障状态，第一处理节点可以指示第二线程在共享内存中存储服务请求关联的上下文信息后休眠。若在第二线程向第二OS发送服务请求之后确定第二OS处于故障状态，则该服务请求可能已被第二OS侧接收到，在第二OS故障恢复后，第二OS可自行为该服务请求调度可用的第一线程以及由该第一线程对该服务请求进行处理，此过程对第一OS侧的进程/线程的运行无影响，第一OS只需正常执行本申请实施例的跨OS系统调用过程即可，在此不再赘述。
相应地，在图10或图11所示的各种故障时机下，若第二OS侧从故障状态恢复至非故障状态，第一OS侧还需快速自愈，以向第二OS重新发起系统调用。
如图12所示，第一OS和第二OS的故障自愈过程可以包括以下步骤：
S1201：第二OS从故障状态恢复至非故障状态。
S1202：在第二OS的内核中快速创建服务线程池，该服务线程池中可以包括多个内核线程，用于对来自第一OS的跨OS系统调用请求触发的服务请求进行处理。
S1203：第一OS侧感知第二OS从故障状态恢复至非故障状态。例如第二APP检测到第二OS从故障状态恢复为非故障状态。
S1204：对故障时发生休眠的任务进行唤醒，恢复当时的任务的上下文状态并完成数据的校验。
示例性地，若所述第一处理节点休眠时所述第二OS从故障状态恢复为非故障状态，该第一OS可以从共享内存中读取所述第一系统调用请求关联的上下文信息，并唤醒所述第一处理节点。第一处理节点可以基于共享内存中的管理信息对该第一系统调用请求关联的上下文信息进行校验，以校验故障前数据的完整性。
或者例如，若第二线程休眠时所述第二OS从故障状态恢复为非故障状态，第一处理节点从共享内存中读取所述服务请求关联的上下文信息，并唤醒第二线程，该第二线程可以基于共享内存中的管理信息对该服务请求关联的上下文信息进行校验，以校验故障前数据的完整性。
S1205：使唤醒的任务重新发起面向第二OS的跨OS系统调用服务。
例如，第一处理节点备唤醒后，第一APP可以根据第一系统调用请求关联的上下文信息重新发起第一系统调用请求，所述第一处理节点响应于该第一系统调用请求重新向第二OS发送服务请求。
或者例如，第二线程被唤醒后，第二线程可以基于所述服务请求关联的上下文信息重新向所述第二OS发送服务请求。
相应地，在第二OS侧，第三处理节点可以重新接收来自第一OS的跨OS系统服务请求，并为该服务请求调用可用的第一线程，来对该服务请求进行处理。此过程与前文结合图8-图9的描述相同，具体实现可参见前文的相关描述在此不再赘述。
由此，通过上述方法，在跨OS系统调用的过程中，通过在跨OS系统调用执行流的不同检查点检测第二OS的状态，并在不同的故障发生时机下保存任务的上下文信息，并将相应任务的执行节点和/或线程休眠，也即将此跨OS系统调用过程休眠，以暂停执行跨OS系统调用，以免该跨OS系统调用相关的服务请求无法被故障的第二OS接收到而影响第一OS侧的第一APP的运行。相应地，基于该故障自愈机制，在第二OS侧故障恢复后，第一OS侧还可以通过唤醒被休眠的节点和/或线程，来重新执行面向第二OS的跨系统调用，提升整个系统的健壮性和鲁棒性。
在基于上述方案的车辆的计算节点上，相比于图4所示的计算平台，能够提升第一OS对于标准POSIX接口的支持能力。相比于图5所示的计算平台，可在第二OS的内核中由内核线程提供系统服务、且来自第一OS的服务请求中不包含线程上下文状态信息，使得第一OS中的APP线程可以绑定第二OS的任一通用内核线程作为服务线程来对跨OS系统服务请求进行处理，能够有效降低通信数据量，同时极大地缩短第二OS侧的服务线程的创建时延，提升跨OS系统服务调用的关键路径性能。在此基础上再实施故障自愈机制，使得第一OS的APP任务可以自愈运行，有助于整个计算节点到达满足功能安全、性能、生态的较佳状态。
应理解，上述方法流程仅是以跨OS系统调用服务为例进行示例说明而非任何限定，该方法同样适用于在第一OS侧向第二OS侧发起缺页处理流程或者维测流程等，通过跨OS系统的处理过程，使得第一OS侧能够复用第二OS侧提供的各种资源和服务，使得第一OS能够复用第二OS的生态。例如，第一OS支持复用第二OS的磁盘文件系统的能力，运行在第一OS的APP文件可以保存在第二OS，在缺页处理过程中，利用本申请实施例的方法，可以将该APP的文件从第二OS侧读取至第一OS侧。或者例如，第一OS支持复用第二OS终端的能力，利用本申请实施例的方法，可以实现在第二OS侧调试第一OS的能力。
上述方法同样可以适用于在多域芯片架构场景下实现跨OS系统调用服务，具体实施方式与上文中结合图8-图12的流程相同，具体实施细节可以参见前文的相关描述，在此不再赘述。另外，上述方法还可以适用于双芯片架构场景下，部署在不同芯片的处理器的OS可以通过两芯片之间的网络通信通道交互信息，以使一个芯片上的操作系统可以申请和使用另一芯片提供的资源或服务，同样还可以通过本申请实施例的故障自愈机制，提升整个芯片系统的健壮性和鲁棒性。
本申请实施例还提供了一种通信装置，用于执行上述方法实施例中第一OS或者第二OS等所执行的方法，相关特征可参见上述方法实施例，在此不再赘述。
如图13所示，在一个示例中，通信装置1300可以包括：第一APP 1301，用于发起第一系统调用请求，所述第一系统调用请求中包括第一服务的服务标识；收发单元1302，用于根据所述服务标识向所述第二OS发送服务请求。如图14所示，在另一个示例中，通信装置1400可以包括：收发单元1401，用于接收所述服务请求，并从多个线程中为所述服务请求分配可用的第一线程；第一线程1402，用于对所述服务请求进行处理。具体实现方式，请参考上述方法实施例中第一OS或第二OS所实现的方法步骤，这里不再赘述。
应理解，以上装置中各单元的划分仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。此外，装置中的单元可以以处理器调用软件的形式实现；例如装置包括处理器，处理器与存储器连接，存储器中存储有指令，处理器调用存储器中存储的指令，以实现以上任一种方法或实现该装置各单元的功能，其中处理器例如为通用处理器，例如中央处理单元(Central Processing Unit，CPU)或微处理器，存储器为装置内的存储器或装置外的存储器。或者，装置中的单元可以以硬件电路的形式实现，可以通过对硬件电路的设计实现部分或全部单元的功能，该硬件电路可以理解为一个或多个处理器；例如，在一种实现中，该硬件电路为专用集成电路(application-specific integrated circuit，ASIC)，通过对电路内元件逻辑关系的设计，实现以上部分或全部单元的功能；再如，在另一种实现中，该硬件电路为可以通过可编程逻辑器件(programmable logic device，PLD)实现，以现场可编程门阵列(Field Programmable Gate Array，FPGA)为例，其可以包括大量逻辑门电路，通过配置文件来配置逻辑门电路之间的连接关系，从而实现以上部分或全部单元的功能。以上装置的所有单元可以全部通过处理器调用软件的形式实现，或全部通过硬件电路的形式实现，或部分通过处理器调用软件的形式实现，剩余部分通过硬件电路的形式实现。
在本申请实施例中，处理器是一种具有信号的处理能力的电路，在一种实现中，处理器可以是具有指令读取与运行能力的电路，例如CPU、微处理器、图形处理器(graphics processing unit，GPU)(可以理解为一种微处理器)、或数字信号处理器(digital singnal processor，DSP)等；在另一种实现中，处理器可以通过硬件电路的逻辑关系实现一定功能，该硬件电路的逻辑关系是固定的或可以重构的，例如处理器为ASIC或PLD实现的硬件电路，例如FPGA。在可重构的硬件电路中，处理器加载配置文档，实现硬件电路配置的过程，可以理解为处理器加载指令，以实现以上部分或全部单元的功能的过程。此外，还可以是针对人工智能设计的硬件电路，其可以理解为一种ASIC，例如神经网络处理单元(Neural Network Processing Unit，NPU)张量处理单元(Tensor Processing Unit，TPU)、深度学习处理单元(Deep learning Processing Unit,DPU)等。
可见，以上装置中的各单元可以是被配置成实施以上方法的一个或多个处理器(或处理电路)，例如：CPU、GPU、NPU、TPU、DPU、微处理器、DSP、ASIC、FPGA，或这些处理器形式中至少两种的组合。
此外，以上装置中的各单元可以全部或部分可以集成在一起，或者可以独立实现。在一种实现中，这些单元集成在一起，以片上系统(system-on-a-chip，SOC)的形式实现。该SOC中可以包括至少一个处理器，用于实现以上任一种方法或实现该装置各单元的功能，该至少一个处理器的种类可以不同，例如包括CPU和FPGA，CPU和人工智能处理器，CPU和GPU等。
在一个简单的实施例中，本领域的技术人员可以想到上述实施例中的通信装置均可采用图15所示的形式。
如图15所示的装置1500，包括至少一个处理器1510和通信接口1530。在一种可选的设计中，还可以包括存储器1520。
本申请实施例中不限定上述处理器1510以及存储器1520之间的具体连接介质。
在如图15的装置中，处理器1510在与其他设备进行通信时，可以通过通信接口1530进行数据传输。
当通信装置采用图15所示的形式时，图15中的处理器1510可以通过调用存储器1520中存储的计算机执行指令，使得装置1500可以执行上述任一方法实施例。
本申请实施例还涉及一种芯片系统，该芯片系统包括处理器，用于调用存储器中存储的计算机程序或计算机指令，以使得该处理器执行上述任一实施例的方法。
在一种可能的实现方式中，该处理器可以通过接口与存储器耦合。
在一种可能的实现方式中，该芯片系统还可以直接包括存储器，该存储器中存储有计算机程序或计算机指令。
示例地，存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(doubledata rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。
本申请实施例还涉及一种处理器，该处理器用于调用存储器中存储的计算机程序或计算机指令，以使得该处理器执行上述任一实施例所述的方法。
示例地，在本申请实施例中，处理器是一种集成电路芯片，具有信号的处理能力。例如，该处理器可以是FPGA，可以是通用处理器、DSP、ASIC或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，还可以是系统芯片(system on chip，SoC)，还可以是CPU，还可以是网络处理器(network processor，NP)，还可以是微控制器(micro controller unit，MCU)，还可以是PLD或其他集成芯片，可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。
在一种可能的实现方式中，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有程序代码，当所述程序代码在所述计算机上运行时，使得计算机执行上述方法实施例。
在一种可能的实现方式中，本申请实施例提供了一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行上述方法实施例。
因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然，本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例范围。这样，倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。在本申请的各个实施例中，如果没有特殊说明以及逻辑冲突，各个实施例之间的术语和/或描述具有一致性、且可以相互引用，不同的实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。

Claims (28)

  1. 一种系统调用方法，其特征在于，应用于车辆的计算节点，所述计算节点包括第一操作系统OS和第二OS，所述第一OS上运行有第一应用程序APP，所述方法包括：
    所述第一APP发起第一系统调用请求，所述第一系统调用请求中包括第一服务的服务标识；
    所述第一OS根据所述服务标识向所述第二OS发送服务请求；
    所述第二OS接收所述服务请求，并从多个线程中为所述服务请求分配可用的第一线程；
    所述第一线程对所述服务请求进行处理。
  2. 根据权利要求1所述的方法，其特征在于，所述第一系统调用请求中还包括所述第一服务关联的系统调用参数，所述第一OS根据所述服务标识向所述第二OS发送服务请求，包括：
    所述第一OS向共享内存申请第一内存空间，并在所述第一内存空间中存储所述第一服务关联的系统调用参数；
    所述第一OS通过所述共享内存向所述第二OS发送所述服务请求，所述服务请求中包括所述服务标识和第一地址，所述第一地址为所述第一服务关联的系统调用参数在所述第一内存空间中的存储地址。
  3. 根据权利要求2所述的方法，其特征在于，所述第一线程对所述服务请求进行处理，包括：
    所述第一线程在所述第二OS上运行时，根据所述第一地址从所述第一内存空间中读取所述第一服务关联的系统调用参数，并根据所述系统调用参数对所述服务请求进行处理。
  4. 根据权利要求1-3中任一项所述的方法，其特征在于，所述方法还包括：
    所述第一OS获取所述第二OS的状态信息，所述状态信息包括故障状态或者非故障状态；
    所述第一OS根据所述服务标识向所述第二OS发送服务请求，包括：
    若所述第二OS处于非故障状态，所述第一OS根据所述服务标识向所述第二OS发送服务请求。
  5. 根据权利要求4所述的方法，其特征在于，所述第一OS中包括第一处理节点，所述第一处理节点至少用于响应于所述第一系统调用请求向所述第二OS发送所述服务请求，所述方法还包括：
    所述第一处理节点确定所述第二OS是否处于故障状态；
    其中，若所述第一处理节点在所述第一APP发起所述第一系统调用请求之前确定所述第二OS处于故障状态，所述方法还包括：
    所述第一处理节点在所述第一OS和所述第二OS的共享内存中存储所述第一系统调用请求关联的上下文信息后休眠。
  6. 根据权利要求5所述的方法，其特征在于，若所述第一处理节点休眠时所述第二OS从故障状态恢复为非故障状态，所述方法还包括：
    所述第一OS从所述共享内存中读取所述第一系统调用请求关联的上下文信息，并唤醒所述第一处理节点；
    所述第一APP根据所述第一系统调用请求关联的上下文信息重新发起第一系统调用请求；
    所述第一处理节点响应于所述第一系统调用请求重新向所述第二OS发送服务请求。
  7. 根据权利要求5或6所述的方法，其特征在于，所述第一OS中包括所述第一APP关联的第二线程，所述第一处理节点用于管理所述第二线程，所述第二线程用于向所述第二OS发送所述服务请求，所述方法还包括：
    所述第二线程确定所述第二OS是否处于故障状态；
    其中，若所述第二线程在向所述第二OS发送所述服务请求的过程中确定所述第二OS处于故障状态，所述方法还包括：
    所述第二线程在所述共享内存中存储所述服务请求关联的上下文信息后休眠。
  8. 根据权利要求7所述的方法，其特征在于，若所述第二线程休眠时所述第二OS从故障状态恢复为非故障状态，所述方法还包括：
    所述第一处理节点从所述共享内存中读取所述服务请求关联的上下文信息，并唤醒所述第二线程；
    所述第二线程基于所述服务请求关联的上下文信息重新向所述第二OS发送服务请求。
  9. 根据权利要求4-8中任一项所述的方法，其特征在于，所述第一OS上还运行有第二APP，所述第一OS获取所述第二OS的状态信息，包括：
    所述第二AP P周期性地发起第二系统调用请求；
    所述第一OS响应于所述第二系统调用请求向所述第二OS发送服务请求，并根据所述第二OS对所述服务请求的应答信息获取所述第二OS的状态信息。
  10. 根据权利要求1-9中任一项所述的方法，其特征在于，所述方法还包括：
    所述第二OS获取所述第一APP对实现所述第一服务的线程的需求信息，并根据所述需求信息释放所述多个线程中的至少一个线程，或者，根据所述需求信息为所述多个线程新建至少一个线程。
  11. 根据权利要求1-10中任一项所述的方法，其特征在于，所述计算节点通过虚拟机提供不同的虚拟运行环境，所述第一OS和所述第二OS运行在所述计算节点的不同虚拟运行环境中。
  12. 根据权利要求1-11中任一项所述的方法，其特征在于，所述第一APP运行时还通过调用所述第一OS提供第二服务，其中，所述第一APP包括自动驾驶相关的至少一个APP，所述至少一个APP用于提供以下的至少一种服务：
    感知服务、融合处理服务或者规控服务；
    所述第二服务包括所述自动驾驶相关APP涉及的调度服务、进程管理服务或者内存管理服务中的至少一种，所述第一服务包括所述自动驾驶相关APP涉及的文件管理、中断管理或者通信管理中的至少一种。
  13. 一种跨系统调用方法，其特征在于，应用于第一操作系统OS，所述第一OS部署在第一处理器，所述第一处理器设置在第一芯片上，所述第一OS上运行有第一APP，所述方法包括：
    所述第一APP发起跨系统调用请求，所述跨系统调用请求中包括第一服务的服务标识，所述第一服务由第二OS提供，所述第二OS部署在第二处理器，所述第二处理器设置在第二芯片上；
    所述第一OS根据所述服务标识向所述第二OS发送跨系统服务请求，所述跨系统服务请求用于请求所述第二OS分配可用的第一线程，所述第一线程用于对所述跨系统服务请求进行处理。
  14. 根据权利要求13所述的方法，其特征在于，所述第一芯片和所述第二芯片之间基于网络通信，所述第一OS根据所述服务标识向所述第二OS发送跨系统服务请求，包括：
    所述第一OS通过所述网络向所述第二OS发送跨系统服务请求，所述跨系统服务请求中包括所述服务标识和所述第一服务关联的跨系统调用参数。
  15. 根据权利要求13或14所述的方法，其特征在于，所述方法还包括：
    所述第一OS获取所述第二OS的状态信息，所述状态信息包括故障状态或者非故障状态；
    所述第一OS根据所述服务标识向所述第二OS发送跨系统服务请求，包括：
    若所述第二OS处于非故障状态，所述第一OS根据所述服务标识向所述第二OS发送服务请求。
  16. 根据权利要求15所述的方法，其特征在于，所述第一OS中包括第一处理节点，所述第一处理节点至少用于响应于所述跨系统调用请求向所述第二OS发送所述跨系统服务请求，所述方法还包括：
    所述第一处理节点确定所述第二OS是否处于故障状态；
    其中，若所述第一处理节点在所述第一APP发起所述跨系统调用请求之前确定所述第二OS处于故障状态，所述方法还包括：
    所述第一处理节点在所述第一OS可访问的存储介质中存储所述第一系统调用请求关联的上下文信息后休眠。
  17. 根据权利要求15所述的方法，其特征在于，若所述第一处理节点休眠时所述第二OS从故障状态恢复为非故障状态，所述方法还包括：
    所述第一OS从所述存储介质中读取所述跨系统调用请求关联的上下文信息，并唤醒所述第一处理节点；
    所述第一APP根据所述跨系统调用请求关联的上下文信息重新发起跨系统调用请求；
    所述第一处理节点响应于所述跨系统调用请求重新向所述第二OS发送跨系统服务请求。
  18. 根据权利要求16或17所述的方法，其特征在于，所述第一OS中包括所述第一APP关联的第二线程，所述第一处理节点用于管理所述第二线程，所述第二线程用于向所述第二OS发送所述跨系统服务请求，所述方法还包括：
    所述第二线程确定所述第二OS是否处于故障状态；
    其中，若所述第二线程在向所述第二OS发送所述跨系统服务请求的过程中确定所述第二OS处于故障状态，所述方法还包括：
    所述第二线程在所述存储介质中存储所述服务请求关联的上下文信息后休眠。
  19. 根据权利要求18所述的方法，其特征在于，若所述第二线程休眠时所述第二OS从故障状态恢复为非故障状态，所述方法还包括：
    所述第一处理节点从所述存储介质中读取所述跨系统服务请求关联的上下文信息，并唤醒所述第二线程；
    所述第二线程基于所述跨系统服务请求关联的上下文信息重新向所述第二OS发送跨系统服务请求。
  20. 根据权利要求15-19中任一项所述的方法，其特征在于，所述第一OS上还运行有第二APP，所述第一OS获取所述第二OS的状态信息，包括：
    所述第二AP P周期性地发起跨系统调用请求；
    所述第一OS响应于所述跨系统调用请求向所述第二OS发送跨系统服务请求，并根据所述第二OS对所述跨系统服务请求的应答信息获取所述第二OS的状态信息。
  21. 一种跨系统调用方法，其特征在于，应用于第二操作系统OS，所述第二操作系统部署在第二处理器，所述第二处理器设置在第二芯片上，所述方法包括：
    所述第二OS接收来自第一OS的跨系统服务请求，所述第一OS部署在第一处理器，所述第一处理器设置在第一芯片上，所述第一OS上运行有第一APP，所述服务请求为所述第一OS响应于所述第一APP发起的跨系统调用请求发送的；
    所述第二OS从多个线程中为所述跨系统服务请求分配可用的第一线程，所述第一线程用于对所述跨系统服务请求进行处理。
  22. 根据权利要求21所述的方法，其特征在于，所述第一芯片和所述第二芯片之间基于网络通信，所述第二OS接收来自第一OS的跨系统服务请求，包括：
    所述第二OS通过所述网络接收来自第一OS的跨系统服务请求，所述跨系统服务请求中包括所述服务标识和所述第一服务关联的跨系统调用参数。
  23. 根据权利要求20或21所述的方法，其特征在于，所述方法还包括：
    所述第二OS获取所述第一APP对实现所述第一服务的线程的需求信息，并根据所述需求信息释放所述多个线程中的至少一个线程，或者，根据所述需求信息为所述多个线程新建至少一个线程。
  24. 一种通信装置，其特征在于，所述通信装置包括：
    通信接口，用于与其他装置进行通信；
    处理器，与所述通信接口耦合，使得所述通信装置执行如权利要求1-12中任意一项所述的方法，或权利要求13-20中任意一项所述的方法，或权利要求21-23中任意一项所述的方法。
  25. 一种芯片系统，其特征在于，包括至少一个处理器和接口电路，所述处理器用于通过所述接口电路执行指令和/或数据的交互，使得所述芯片系统执行权利要求1-12中任一项所述的方法，或者执行权利要求13-20中任一项所述的方法，或者执行权利要求21-23中任一项所述的方法。
  26. 一种车辆，其特征在于，包括计算节点，所述计算节点用于实现如权利要求1-12中任一项所述的方法，或者用于实现如权利要求13-20，或者用于实现如权利要求21-23中任一项所述的方法。
  27. 一种计算机可读存储介质，其特征在于，包括程序或指令，当所述程序或指令被执行时，如权利要求1-12中任意一项所述的方法被执行，或者如权利要求13-20中任一项所述的方法被执行，或者如权利要求21-23中任一项所述的方法被执行。
  28. 一种计算机程序产品，其特征在于，当计算机读取并执行所述计算机程序产品时，使得计算机执行如权利要求1-12中任一项所述的方法，或者执行如权利要求13-20中任一项所述的方法，或者执行如权利要求21-23中任一项所述的方法。
PCT/CN2025/083868 2024-03-25 2025-03-20 一种系统调用方法和装置 Pending WO2025201178A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202410349538.7 2024-03-25
CN202410349538.7A CN120743423A (zh) 2024-03-25 2024-03-25 一种系统调用方法和装置

Publications (1)

Publication Number Publication Date
WO2025201178A1 true WO2025201178A1 (zh) 2025-10-02

Family

ID=97217230

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2025/083868 Pending WO2025201178A1 (zh) 2024-03-25 2025-03-20 一种系统调用方法和装置

Country Status (2)

Country Link
CN (1) CN120743423A (zh)
WO (1) WO2025201178A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109582453A (zh) * 2018-11-29 2019-04-05 北京元心科技有限公司 多系统间协调调度的方法、装置及电子设备
CN116795557A (zh) * 2022-03-15 2023-09-22 华为技术有限公司 通信方法、电子设备及可读存储介质
CN116932245A (zh) * 2023-06-30 2023-10-24 中科方德软件有限公司 一种远程调用方法、装置、电子设备及存储介质
CN116980147A (zh) * 2022-04-22 2023-10-31 上海集度汽车有限公司 业务处理方法、装置、系统及车辆

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109582453A (zh) * 2018-11-29 2019-04-05 北京元心科技有限公司 多系统间协调调度的方法、装置及电子设备
CN116795557A (zh) * 2022-03-15 2023-09-22 华为技术有限公司 通信方法、电子设备及可读存储介质
CN116980147A (zh) * 2022-04-22 2023-10-31 上海集度汽车有限公司 业务处理方法、装置、系统及车辆
CN116932245A (zh) * 2023-06-30 2023-10-24 中科方德软件有限公司 一种远程调用方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
CN120743423A (zh) 2025-10-03

Similar Documents

Publication Publication Date Title
US9904527B1 (en) Optimizing API implementer programs using fine-grained code analysis
US8276145B2 (en) Protected mode scheduling of operations
CN109522099B (zh) 提高非实时性操作系统实时性的方法及其系统
KR102485288B1 (ko) 차량용 제어기 및 그것의 운영체제 스케쥴링 방법
US8051281B2 (en) Operating system startup control method and information processing apparatus
CN107423619B (zh) 一种基于虚拟化技术构建智能终端web运行时的方法
CN113391821B (zh) 一种非对称多处理器嵌入式操作系统
US20210389966A1 (en) Micro kernel based extensible hypervisor and embedded system
WO2020028509A1 (en) Method and apparatus for software isolation and security utilizing multi-soc orchestration
KR20240033083A (ko) 차량-장착 운영 체제, 디버깅 시스템 및 방법, 전자 디바이스 및 저장 매체
CN112306669B (zh) 一种基于多核系统的任务处理方法及装置
CN117891515B (zh) 智能座舱的实现方法、智能座舱、计算机可读介质
CN118796285A (zh) 一种应用于采集终端的多核操作系统架构
CN118426912B (zh) 基于gpu的用户容器处理方法、装置、设备及介质
CN116360941A (zh) 一种面向多核dsp的并行计算资源自组织调度方法及系统
CN116627644B (zh) 计算资源调度方法、装置、设备及存储介质
CN114546642B (zh) 任务执行方法、装置、计算机设备、存储介质和程序产品
CN116382713A (zh) 构建应用镜像的方法、系统、设备和存储介质
WO2025201178A1 (zh) 一种系统调用方法和装置
EP4148573A1 (en) Method to execute a mode-transition in a multi-mode computer system
CN113377407B (zh) 基于posix接口的域控制器刷新方法和装置
EP4575777A1 (en) Driving system and construction method therefor, vehicle and storage medium
CN115828231B (zh) 应用程序运行方法、装置、车辆以及存储介质
Kohn et al. Timing analysis for hypervisor-based I/O virtualization in safety-related automotive systems
CN117707748A (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: 25778726

Country of ref document: EP

Kind code of ref document: A1