SYSTEM

FIELD

[01] The present technology relates to software management of hardware peripherals. In particular, a method and a system aim at treating interrupts in an embedded system.

BACKGROUND

[02] A computer system purposed-built for a set of dedicated functions is oftentimes called an embedded system. Embedded systems generally combine processing capabilities of a computer with electrical, electronical, optical and/or mechanical hardware components that operate the dedicated functions. Embedded systems are frequently subject to real-time requirements.

[03] As an example, telecommunication systems and data centers may be based on highly expandable and configurable chassis-based switches. An example of a chassis-based switch comprises a central processing unit (CPU) built on one or a plurality of processors, and a frame providing a plurality of connections, such as slots, adapted to interface with hardware peripherals, for example line cards, together forming an embedded system.

[04] One of the important aspects of embedded systems is the ability to manage hardware peripherals efficiently. An important measure of this efficiency is the latency in which a control entity, typically a microprocessor running embedded software, reacts to an event indicated by the peripheral. In most conventional implementations, this control involves the hardware peripheral raising an interrupt and causing the microprocessor to service the interrupt with appropriate actions.

[05] FIG. 1 is a block diagram of a first conventional software architecture of an embedded system. An embedded system 10 has a software architecture, supported by a CPU, and generally divided between two (2) sections including a host kernel space 12 and a host user space 30. The host kernel space 12 is the operating system of the embedded system 10. The host user space 30 includes one or more applications that support the various functionalities of the embedded system 10. [06] In more details, the embedded system 10 uses interrupt injection. The host kernel space 12 includes a context switch 14 that includes a host interrupt service routine (ISR) to receive and handle interrupts 16 from one or more hardware peripherals (not shown) of the embedded system 10. The interrupts 16 are real-time notifications from the hardware peripherals. Upon receiving an interrupt 16, the context switch 14 pauses the execution of ongoing processes of the embedded system 10 and stores in a memory (not specifically shown) a current state of the embedded system 10 so that the ongoing processes may be restarted at a later time. The context switch 14 provides information about the interrupt 16 to a driver 18. The host kernel 12 may include one or more drivers 18 adapted to interface with one or more hardware peripherals. The driver 18 may perform some of the tasks required to handle the interrupt 16 but, generally, additional processing in the host user space 30 is required to properly handle the interrupt 16. The interrupt 16 is translated by a hypervisor 20 that virtualizes the interrupt 16 for its re-injection into a virtual machine (VM). A re-injected interrupt 22 is forwarded by the hypervisor 20 to the host user space 30. [07] In the host user space 30, an interrupt buffer 32 receives the re-injected interrupt 22 and provides an indication 34 of the ongoing interrupt to a virtual machine (VM) 36. The VM 36 implements a guest kernel space 40 and a guest user space 50. The guest kernel space 50 acts as a pseudo operating system of the VM 36 while the guest user space 50 supports the actual dedicated functions of the embedded system 10 for supporting the one or more hardware peripherals.

[08] The guest kernel space 40 includes a guest context switch 42 that generally replicates the context switch 14 of the host kernel 12. The guest context switch 42 is triggered by the indication 34 of the ongoing interrupt and pauses the execution of ongoing processes of the VM 36 and stores in a memory (not specifically shown) a current state of the VM 36 so that the ongoing processes may be restarted at a later time. The guest context switch 42 provides information about the indication 34 of the ongoing interrupt to a guest driver 44.

[09] The guest kernel space 50 includes a user application 52 in which dedicated software acts upon the interrupt 16 the hardware peripheral. The user application 52 provides a response, generally in the form of a hardware command, to the interrupt 16 that is forwarded to the guest driver 44 and further to the guest context switch 42. Having recuperated the state of the VM 36 from the memory and resumed execution of the processes previously ongoing in the VM 36, the guest context switch 42 forwards the command to the interrupt buffer 32. The command is further forwarded through to the hypervisor 20 and to the driver 18, which acts on the command for the benefit of the hardware peripheral. Finally, the context switch 14 recuperates the state of the embedded system 10 from the memory and resumes execution of the processes previously ongoing in the embedded system 10.

[10] As person skilled in the art may appreciate, the architecture of the embedded system 10 may not be optimal in that the complexity of repeated, recursive context switches may be a cause of performance penalties, making it difficult to meet latency requirements of real-time or near-real-time applications. [11] FIG. 2 is a block diagram of a second conventional software architecture of an embedded system. An embedded system 60 shares some of the elements of the embedded system 10 of FIG. 1. Like numerals are used in FIGS 1 and 2 to reflect the same or equivalent components of these conventional embedded system variants. The embedded system 60 also has a software architecture, supported by a CPU, and generally divided between two (2) sections including a host kernel space 12 and a host user space 30.

[12] The embedded system 60 uses interrupt emulation. The VM 66 comprises an interrupt controller emulator, shown as an emulated advanced programmable interrupt controller (APIC) 38 on FIG. 2. The host kernel space 12 communicates with the emulated APIC 38 through the interrupt buffer 32. The emulated APIC 38 effectively isolates the guest kernel space 40 and the guest user space 50 from the actual hardware peripheral. As a result, the user application 52 (shown on FIG. 1) only communicates with the emulated APIC 38.

[13] The embedded system 60 thus relies on software emulators. The required processing overhead required to simulate interrupts is significantly higher than in the case of the embedded system 10 of FIG. 1. For that reason, the embedded system 60 may not meet latency requirements of demanding real-time applications.

[14] Yet another conventional solution relies on the use of processors equipped with an input-output memory management unit (IOMMU) and specific basic input output system (BIOS) enhancements. Such processors are available for example from AMD™ and from Intel™. Systems built using those processors allow direct handling of interrupts and like hardware indications at the level of the virtual machine. However, many processors and microprocessors used in conventional embedded systems do not have these features. Moreover, IOMMU-equipped processors are typically expensive and have important power constraints.

[15] Even though the above-described technologies may support interrupt management to some extent, improvements may still be desirable, in particular, improvements aiming at treating interrupts in an embedded system.

SUMMARY

[16] It is an object of present technology to provide improvements, in particular improvements aiming at treating interrupts in an embedded system.

[17] The present technology arises from an observation made by the inventor(s) the present manner of treating interrupts received from peripheral hardware devices may be relied upon to improve the functioning of computer-based embedded systems. In some embodiments, the present technology may be implemented using general-purpose processors without relying on specific hardware additions. In some embodiments, the present technology may not need to rely on recursive context switches. In some embodiments, an interrupt received in a host device driver from a hardware device is translated in a blocking signal by a proxy, and then treated by an application device driver that generates a control signal for translation into a command that is, in turn, for execution by the host device driver. The host device driver, the proxy and the application device driver may be processed by a processor coupled to a memory device. In some embodiments, the embedded system may comprise a plurality of application device drivers supporting a plurality of hardware devices. In the same or other embodiments, the application device driver may be part of a virtual machine in the embedded system.

[18] Thus, in one aspect, various implementations of the present technology provide a method of treating interrupts in an embedded system, comprising: receiving, at a host device driver, an interrupt comprising a designation of a hardware device; sending, from the host device driver toward a proxy, an indication of the interrupt, the indication of the interrupt being associated with the designation of the hardware device; translating, at the proxy, the indication of the interrupt into a blocking signal, the blocking signal being associated with the designation of the hardware device; sending, from the proxy toward an application device driver, the blocking signal; generating, at the application device driver, a control signal in response to the blocking signal, the control signal being associated with the designation of the hardware device; sending, from the application device driver toward the proxy, the control signal; translating, at the proxy, the control signal into a command, the command being associated with the designation of the hardware device; sending, from the proxy toward the host device driver, the command; and executing the command at the host device driver.

[19] In some implementations, the application device driver, the proxy and the host device driver are configured to be processed by a processor, the processor being coupled to a memory device.

[20] In some further implementations, the host device driver stores associations between each of a first plurality of application device drivers and a second plurality of hardware devices.

[21] In some implementations, the proxy selects the application device driver among the first plurality of application device drivers based on the designation of the hardware device.

[22] In some further implementations, the host device driver comprises a plurality of interrupt monitoring threads, each one of the plurality of interrupt monitoring threads being assigned to a corresponding one of the plurality of hardware devices.

[23] In some implementations, generating the control signal in response to the blocking signal further comprises executing an interrupt service routine at the application device driver.

[24] In some further implementations, the host device driver is part of a host kernel, and the application device driver is part of a virtual machine. [25] In some implementations, a plurality of application device drivers is distributed among a plurality of virtual machines.

[26] In some further implementations, a memory comprises a host kernel partition and an emulator partition, the host kernel partition comprising the host kernel, the emulator partition comprising the proxy and the virtual machine.

[27] In some implementations, the emulator partition defines a plurality of virtual processors and wherein operations of the application device driver are executed on one of the plurality of virtual processors.

[28] In some further implementations, the virtual machine comprises a front end driver interfacing with the proxy and comprising the application device driver.

[29] In some implementations, the method further comprises: receiving, at the front end driver, the blocking signal; converting, at the front end driver, the blocking signal into a pseudo interrupt; generating, at the application device driver, a pseudo command; and converting, at the front end driver, the pseudo command into the control signal.

[30] In some further implementations, the virtual machine further comprises: a blocking queue adapted to sequentially receive, from the proxy, a plurality of blocking signals and to sequentially send the plurality of blocking signals toward the front end driver; and a command queue adapted to sequentially receive, from the front end driver, a plurality of control signals and to sequentially send the plurality of control signals toward the proxy.

[31] In some implementations, the proxy comprises: an interrupt thread adapted to sequentially receive, from the host device driver, a plurality of interrupt indications, to translate the plurality of interrupt indications into a plurality of blocking signals, and to sequentially forward the plurality of blocking signals toward the application device driver; and a command thread adapted to sequentially receive, from the application device driver, a plurality of control signals, to translate the plurality of control signals into a plurality of commands, and to sequentially send the plurality of commands toward the host device driver.

[32] In another aspect, various implementations of the present technology provide an embedded system, comprising: a memory device defining a host kernel partition and a host user space, the host kernel partition comprising a host device driver, the host user space comprising a proxy and an application device driver; a processor in electronic communication with the memory device; and a non-transitory computer readable information storage medium in electronic communication with a processor, the computer readable information storage medium containing program instructions that when executed by the processor effect: receiving, at the host device driver, an interrupt comprising a designation of a hardware device; sending, from the host device driver toward the proxy, an indication of the interrupt, the indication of the interrupt being associated with the designation of the hardware device; translating, at the proxy, the indication of the interrupt into a blocking signal, the blocking signal being associated with the designation of the hardware device; sending, from the proxy toward the application device driver, the blocking signal; generating, at the application device driver, a control signal in response to the blocking signal, the control signal being associated with the designation of the hardware device; sending, from the application device driver toward the proxy, the control signal; translating, at the proxy, the control signal into a command, the command being associated with the designation of the hardware device; sending, from the proxy toward the host device driver, the command; and executing the command at the host device driver.

[33] In some implementations, the host kernel partition comprises a plurality of interrupt monitoring threads defined for a corresponding plurality of hardware devices.

[34] In some further implementations, the host user space comprises an emulator partition. [35] In some implementations, the emulator partition comprises the proxy and a virtual machine, the virtual machine comprising, for each of a plurality of corresponding hardware devices: a corresponding association with one of one or more application device drivers; a corresponding blocking queue; a corresponding command queue; and a corresponding device thread.

[36] In some further implementations, the emulator partition comprises a plurality of virtual central processing unit threads, each virtual central processing unit thread being configured to generate control signals in response to blocking signals. [37] In some implementations, each virtual central processing unit thread contains a distinct application device driver.

[38] In some further implementations, the processor comprises a plurality of cooperating processors.

[39] In the context of the present specification, unless expressly provided otherwise, an "embedded system", and a "computer-based system" are any hardware and/or software appropriate to the relevant task at hand. Thus, some non- limiting examples of hardware and/or software include computers (servers, desktops, laptops, netbooks, etc.), smartphones, tablets, network equipment (routers, switches, gateways, etc.) and/or combination thereof.

[40] In the context of the present specification, unless expressly provided otherwise, the expressions "memory" and "memory device" are intended to include media of any nature and kind whatsoever, non-limiting examples of which include RAM, ROM, disks (CD-ROMs, DVDs, floppy disks, hard disk drives, etc.), USB keys, flash memory cards, solid state-drives, and tape drives.

[41] In the context of the present specification, unless expressly provided otherwise, an "indication" of an information element may be the information element itself or a pointer, reference, link, or other indirect mechanism enabling the recipient of the indication to locate a network, memory, database, or other computer-readable medium location from which the information element may be retrieved. For example, an indication of an interrupt could include the contents of the interrupt, or it could be a unique file descriptor identifying the interrupt contents with respect to a particular file system, or some other means of directing the recipient of the indication to a network location, memory address, database table, or other location where the interrupt contents may be accessed. As one skilled in the art would recognize, the degree of precision required in such an indication depends on the extent of any prior understanding about the interpretation to be given to information being exchanged as between the sender and the recipient of the indication. For example, if it is understood prior to a communication between a sender and a recipient that an indication of an information element will take the form of a database key for an entry in a particular table of a predetermined database containing the information element, then the sending of the database key is all that is required to effectively convey the information element to the recipient, even though the information element itself was not transmitted as between the sender and the recipient of the indication.

[42] Implementations of the present technology each have at least one of the above- mentioned object and/or aspects, but do not necessarily have all of them. It should be understood that some aspects of the present technology that have resulted from attempting to attain the above-mentioned object may not satisfy this object and/or may satisfy other objects not specifically recited herein. [43] Additional and/or alternative features, aspects and advantages of implementations of the present technology will become apparent from the following description, the accompanying drawings and the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS [44] For a better understanding of the present technology, as well as other aspects and further features thereof, reference is made to the following description which is to be used in conjunction with the accompanying drawings, where:

[45] FIG. 1 is a diagram of a computer system suitable for implementing the present technology and/or being used in conjunction with implementations of the present technology; [46] FIG. 2 is a block diagram of a second conventional software architecture of an embedded system;

[47] FIG. 3 is a block diagram of a surrogate driver architecture for managing host hardware peripherals according to an embodiment; and

[48] FIG. 4 is a flowchart illustrating a method of treating interrupts in an embedded system.

DETAILED DESCRIPTION

[49] The examples and conditional language recited herein are principally intended to aid the reader in understanding the principles of the present technology and not to limit its scope to such specifically recited examples and conditions. It will be appreciated that those skilled in the art may devise various arrangements which, although not explicitly described or shown herein, nonetheless embody the principles of the present technology and are included within its spirit and scope.

[50] Furthermore, as an aid to understanding, the following description may describe relatively simplified implementations of the present technology. As persons skilled in the art would understand, various implementations of the present technology may be of a greater complexity. [51] In some cases, what are believed to be helpful examples of modifications to the present technology may also be set forth. This is done merely as an aid to understanding, and, again, not to define the scope or set forth the bounds of the present technology. These modifications are not an exhaustive list, and a person skilled in the art may make other modifications while nonetheless remaining within the scope of the present technology. Further, where no examples of modifications have been set forth, it should not be interpreted that no modifications are possible and/or that what is described is the sole manner of implementing that element of the present technology.

[52] Moreover, all statements herein reciting principles, aspects, and implementations of the present technology, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof, whether they are currently known or developed in the future. Thus, for example, it will be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the present technology. Similarly, it will be appreciated that any flowcharts, flow diagrams, state transition diagrams, pseudo-code, and the like represent various processes which may be substantially represented in computer-readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

[53] The functions of the various elements shown in the figures, including any functional block labeled as a "processor", may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a computer, by a single shared processor, or by a plurality of individual processors, some of which may be shared. In some embodiments of the present technology, the processor may be a general purpose processor, such as a central processing unit (CPU) or a group of cooperating CPUs, or may alternatively be a processor or a group of co-processors dedicated to a specific purpose, such as a graphics processing unit (GPU). Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read-only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage. Other hardware, conventional and/or custom, may also be included.

[54] Software modules, or simply modules which are implied to be software, may be represented herein as any combination of flowchart elements or other elements indicating performance of process operations and/or textual description. Such modules may be executed by hardware that is expressly or implicitly shown.

[55] In conventional embedded system, the ability to service an interrupt requires significant amount of hardware mechanisms. These mechanisms are only visible to the lowest layer of an operating system (OS) that operates in close synchronicity with the microprocessor, and not exposed to the user space applications of the OS. The present technology organizes software applications inside virtual machines (VM) and provides for accessing these application with reduced overhead.

[56] In an aspect of the present disclosure, when an incident interrupt is received from a hardware device, a host device driver first tackles a few basic services to satisfy the interrupting hardware. Additional services for treating the interrupt are performed in an application device driver that resides inside the VM.

[57] A virtualization software, called a quick emulator (QEMU), provides a proxy that allows a host device driver to interact with the application device driver that resides inside the VM. Inside the VM, a front-end driver that communicates with the proxy implements the same or similar primitives as those supported by the host device driver. Signals are exchanged between the front-end driver and the host device driver, through the proxy.

[58] With these fundamentals in place, we will now consider some non-limiting examples to illustrate various implementations of aspects of the present technology.

[59] Referring to FIG. 3, there is shown a block diagram of a surrogate driver architecture for managing host hardware peripherals according to an embodiment. Software is run in embedded system 100 over a processor such as a central processing unit (CPU) or over a cluster of cooperating processors. The embedded system 100 implements one or more surrogate application device drivers that are part of a virtual machine (VM) or part of a plurality of VMs. These application device drivers do not directly interact with the supported hardware devices, but rather interact therewith through a proxy that translates signals between the VM and a kernel partition that forms an operating system of the embedded system 100.

[60] The embedded system 100 is configured to treat interrupts from N hardware devices (not shown), which are hardware peripherals of the embedded system 100. In some embodiments, there is no a priori limit to the number N of hardware devices supported by the embedded system 100. When constructing the embedded system 100, the number N of supported hardware peripherals is determined by the processing capabilities of the processor or processors on which the embedded system 100 is built, by the number and frequency of interrupts that are expected from each of the N hardware devices, by the amount of processing required for treating each interrupt, and by other similar considerations. In some embodiments, the embedded system 100 is adapted to treat interrupts from one single hardware peripheral, so N is an integer number greater than or equal to one (1).

[61] The software architecture is generally divided between two (2) sections including a host kernel partition 110 and a host user space 130. In at least one embodiment, the host kernel partition 110 and the host user space are supported by the same CPU, or by the same cluster of cooperating CPUs.

[62] The host kernel partition 110 is the operating system of the embedded system 100. It includes N interrupt monitoring threads 112i ... 112N, generally referred herein as interrupt monitoring threads 112i, that act as buffers for receiving interrupt signals from the N corresponding hardware devices.

[63] The host kernel partition 110 also comprises a host device driver 114. The host device driver 114 has a bidding process to store, in a memory space, associations between each of the N hardware devices of the embedded system 100 and each of one or more corresponding application device drivers that are part of the VM. [64] This bidding process may take place, for example, upon initial configuration or upon reconfiguration of the application device drivers in the VM. The associations stored in the host device driver 114 allow exchanging signals between the host kernel partition 110 and the host user space 130 using a common set of hardware device designations. [65] The host user space 130 forms a quick emulator (QEMU) process space 132, which in turn is an emulator partition of the embedded system 100 in which a number of software components are built to provide treatment of interrupts from the N hardware devices. In more details, the QEMU process space 132 comprises an input/output (10) thread 134 that contains a backend (BE) driver 136. The BE driver 136 implements an interrupt thread 138 and a command thread 140 that, together, form a back end proxy for the exchange of signals between the host kernel partition 110 and other components of the host user space 130.

[66] The QEMU process space 132 further comprises one or more virtual processors, called virtual central processing unit (VCPU) threads 150. Without limiting the present disclosure, the components of the host user space 130 as shown on FIG. 3 communicate via an interpreter 142 that uses the VirtIO protocol. The name "VirtIO" is an abbreviation of "virtual input- output"; this protocol is used in virtual computing environments and is described for example at htip://wiki.libvirt.org/page/Virtio. The VirtIO protocol is used in the embodiment of FIG. 3 for practical reasons and without limiting the present disclosure, as it readily available in software platforms that support software virtualization. Using other interpreters to translate signals exchange between the components of the host user space 130 is also contemplated.

[67] The interrupt thread 138 is configured to receive interrupt indications 120 from the host device driver 114. The command thread 140 is configured to forward commands 122 to the host device driver 114. [68] The embedded system 100 may comprise one or a plurality of VCPU threads 150, or virtual processors for running a VM 152. In a particular embodiment comprising two of more VCPU threads 150, each such VCPU thread 150 operates in the same or equivalent manner and generally executes equivalent operations. It should be noted, however, that a first application device driver a particular hardware peripheral of a first type may differ from a second application device driver for another hardware peripheral of a second type. Hence a first driver implemented in a first VCPU thread 150 may differ from a second driver implemented in a second VCPU thread 150. Without limiting the present disclosure and for ease of illustration, the next few paragraphs describe and embodiment of the embedded system 100 that includes a single VCPU thread 150 for simplicity. [69] The VCPU thread 150 includes one or more applications that support the various functionalities of the embedded system 100. The VM 152 implements a front end (FE) driver 154 that is adapted to perform operations that are necessary for the treatment of interrupts from the hardware devices of the embedded system 100. The FE driver 154 interfaces with the interrupt thread 138 and the command thread 140 through the interpreter 142. The FE driver 154 comprises a software implementation of one or more application device drivers that are adapted to provide services to treat the interrupts from the N hardware devices. In an embodiment, each of N distinct application device drivers is adapted to serve a corresponding one of the N hardware devices. In another embodiment, a single application device driver is adapted to serve all the hardware devices. In yet another embodiment, some of the N hardware devices are served by a first application device driver and some other of the N hardware devices are served by a second application device driver. The correspondence between a given hardware device and a given application device driver within the FE driver 154 is an implementation issue for the embedded system 100 and any association between one or more application device drivers and one or more hardware peripherals is within the scope of the present disclosure. [70] The VM 152 also implements N device threads 156i ... 156N, generally referred herein as device threads 156;, that correspond to the N interrupt monitoring threads 112i ... 112N of the host kernel partition 110. The device threads 156i ... 156N communicate, through the interpreter 142, with the interrupt thread 138 and with the command thread 140 via N queues 144i ... 144N, generally referred herein as queues 144i, that may act both as blocking queues and as command queues. Use of distinct parallel queues as blocking queues and as command queues is also contemplated.

[71] Having described the software architecture of the embedded system 100, reference is now made concurrently to FIG. 3 and to FIG. 4, the latter being a flowchart illustrating a method of treating interrupts in an embedded system. A sequence 200 of FIG. 4 includes a plurality of operations, some of which some may be executed in variable order, some of the operations being optional in some embodiments. In operation 210, the host device driver 114 receives an interrupt comprising a designation of a hardware device having generated the interrupt. The interrupt may be received at the host device driver 114 via an interrupt monitoring thread 112; corresponding to a 1 ^TH hardware device. In operation 212, the host device driver 114 sends toward the interrupt thread 138, which acts as a back end proxy the host kernel partition 110 and the host user space 130, an indication 120 of the interrupt, the indication of the interrupt being associated with the designation of the interrupting hardware device. The interrupt thread 138 translates the indication 120 of the interrupt into a blocking signal 124 in operation 214. The blocking signal 124 is associated with the designation of the interrupting hardware device. In the embodiment of FIG. 3 in which the interpreter 142 implements the VirtIO protocol, the blocking signal 124 may be a virtio_notify signal. In operation 216, the interrupt thread 138 initiates sending of the blocking signal 124 toward an application device driver implemented in the FE driver 154. In an embodiment, the interrupt thread 138 may be adapted to sequentially receive a plurality of interrupt indications 120 and to then sequentially send a plurality of blocking signals 124 toward the FE driver 154. The blocking signal 124 may transit through the interpreter 142 and may arrive at the FE driver 154 via a queue 144j, acting as a blocking queue for the interrupting hardware device, and a device thread 156; that also correspond to the interrupting hardware device. In an embodiment, the queue 144; may be adapted to sequentially receive a plurality of blocking signals 124 and to then sequentially send the plurality of blocking signals 124 toward the FE driver 154. [72] The blocking signal 124 reaches the FE driver 154. There may be a plurality of distinct application device drivers that contain different functions for treating interrupts received from distinct hardware devices. The FE driver 154 may select an appropriate one of a plurality of application device drivers based on the designation of the interrupting hardware device contained in the blocking signal 124. In operation 218, the appropriate application device driver in the FE driver 154 executes an interrupt service routine to generate a control signal 126 in response to the blocking signal 124. The control signal 126 is also associated with the designation of the interrupting hardware device.

[73] In an embodiment, the FE driver 154 converts the blocking signal 124 into a pseudo interrupt signal (not shown) that emulates or substantially reproduces the interrupt signal received from the interrupting hardware device, the pseudo interrupt signal being treated by the application device driver within the FE driver 154. In this embodiment, the application device driver generates a pseudo command (not shown) that emulates or substantially reproduces a command for controlling the hardware device and the FE driver 154 converts the pseudo command into the control signal 126. These conversions provide that, in at least this embodiment, it is possible to install in the FE driver 154 a given software implementation of a given application device driver otherwise adapted for implementation in a conventional controller providing a direct interaction between the hardware device. [74] At operation 220, the FE driver 154 sends the control signal 126 toward the command thread 140. The control signal 126 may be a kick signal if the interpreter 142 implements the VirtlO protocol. The control signal 126 may transit through the device thread 156;, through the queue 144; acting as a command queue, and further through the interpreter 142. The queue 144j may be adapted to sequentially receive a plurality of control signals 126 and to then sequentially send the plurality of blocking signals 126 toward the command thread 140. Having received the control signal 126, the command thread 140 translates the control signal 124 into a command 122 at operation 222. The command 122 is also associated with the designation of the interrupting hardware device. At operation 224, the command thread 140 sends the command 122 to the host device driver 114. In a variant, the command thread 140 may be adapted to sequentially receive a plurality of control signals and to then sequentially send a plurality of commands 122 to the host device driver. The host device driver 114 executes the command at operation 226.

[75] It should be expressly understood that implementations of the embedded system 100 and of the method for treating interrupts are provided for illustration purposes only. As such, those skilled in the art will easily appreciate other specific implementational details for the embedded system 100 and for the method for treating interrupts. As such, by no means, examples provided herein above are meant to limit the scope of the present technology.

[76] While the above-described implementations have been described and shown with reference to particular operations performed in a particular order, it will be understood that these operations may be combined, sub-divided, or re-ordered without departing from the teachings of the present technology. Accordingly, the order and grouping of the operations is not a limitation of the present technology.

[77] As such, the methods and systems implemented in accordance with some non-limiting embodiments of the present technology can be represented as follows, presented in numbered clauses.

[Clause 1] A method of treating interrupts in an embedded system, comprising: receiving, at a host device driver, an interrupt comprising a designation of a hardware device; sending, from the host device driver toward a proxy, an indication of the interrupt, the indication of the interrupt being associated with the designation of the hardware device; translating, at the proxy, the indication of the interrupt into a blocking signal, the blocking signal being associated with the designation of the hardware device; sending, from the proxy toward an application device driver, the blocking signal; generating, at the application device driver, a control signal in response to the blocking signal, the control signal being associated with the designation of the hardware device; sending, from the application device driver toward the proxy, the control signal; translating, at the proxy, the control signal into a command, the command being associated with the designation of the hardware device; sending, from the proxy toward the host device driver, the command; and executing the command at the host device driver.

[Clause 2] The method of clause 1, wherein the application device driver, the proxy and the host device driver are configured to be processed by a processor, the processor being coupled to a memory device.

[Clause 3] The method of any one of clauses 1 or 2, further comprising storing, in the host device driver, associations between each of a first plurality of application device drivers and a second plurality of hardware devices.

[Clause 4] The method of clause 3, further comprising selecting, at the proxy, the application device driver among the first plurality of application device drivers based on the designation of the hardware device.

[Clause 5] The method of any one of clauses 3 or 4, wherein the host device driver comprises a plurality of interrupt monitoring threads, each one of the plurality of interrupt monitoring threads being assigned to a corresponding one of the plurality of hardware devices. [Clause 6] The method of any one of clauses 1 to 5, wherein generating the control signal in response to the blocking signal further comprises executing an interrupt service routine at the application device driver.

[Clause 7] The method any one of clauses 1 to 6, wherein: the host device driver is part of a host kernel; and the application device driver is part of a virtual machine.

[Clause 8] The method of clause 7, wherein a plurality of application device drivers is distributed among a plurality of virtual machines.

[Clause 9] The method of any one of clauses 7 or 8, wherein a memory comprises a host kernel partition and an emulator partition, the host kernel partition comprising the host kernel, the emulator partition comprising the proxy and the virtual machine.

[Clause 10] The method of clause 9, wherein the emulator partition defines a plurality of virtual processors and wherein operations of the application device driver are executed on one of the plurality of virtual processors. [Clause 11] The method of any one of clauses 7 to 10, wherein the virtual machine comprises a front end driver interfacing with the proxy and comprising the application device driver.

[Clause 12] The method of clause 11, further comprising: receiving, at the front end driver, the blocking signal; converting, at the front end driver, the blocking signal into a pseudo interrupt; generating, at the application device driver, a pseudo command; and converting, at the front end driver, the pseudo command into the control signal.

[Clause 13] The method of clause 12, wherein the virtual machine further comprises: a blocking queue adapted to sequentially receive, from the proxy, a plurality of blocking signals and to sequentially send the plurality of blocking signals toward the front end driver; and a command queue adapted to sequentially receive, from the front end driver, a plurality of control signals and to sequentially send the plurality of control signals toward the proxy.

[Clause 14] The method of any one of clauses 1 to 13, wherein the proxy comprises: an interrupt thread adapted to sequentially receive, from the host device driver, a plurality of interrupt indications, to translate the plurality of interrupt indications into a plurality of blocking signals, and to sequentially forward the plurality of blocking signals toward the application device driver; and a command thread adapted to sequentially receive, from the application device driver, a plurality of control signals, to translate the plurality of control signals into a plurality of commands, and to sequentially send the plurality of commands toward the host device driver.

[Clause 15] An embedded system, comprising: a memory device defining a host kernel partition and a host user space, the host kernel partition comprising a host device driver, the host user space comprising a proxy and an application device driver; a processor in electronic communication with the memory device; and a non-transitory computer readable information storage medium in electronic communication with the processor, the computer readable information storage medium containing program instructions that when executed by the processor effect: receiving, at the host device driver, an interrupt comprising a designation of a hardware device; sending, from the host device driver toward the proxy, an indication of the interrupt, the indication of the interrupt being associated with the designation of the hardware device; translating, at the proxy, the indication of the interrupt into a blocking signal, the blocking signal being associated with the designation of the hardware device; sending, from the proxy toward the application device driver, the blocking signal; generating, at the application device driver, a control signal in response to the blocking signal, the control signal being associated with the designation of the hardware device; sending, from the application device driver toward the proxy, the control signal; translating, at the proxy, the control signal into a command, the command being associated with the designation of the hardware device; sending, from the proxy toward the host device driver, the command; and executing the command at the host device driver.

[Clause 16] The system of clause 15, wherein the host kernel partition comprises a plurality of interrupt monitoring threads defined for a corresponding plurality of hardware devices.

[Clause 17] The system of any one of clauses 15 or 16, wherein the host user space comprises an emulator partition.

[Clause 18] The system of clause 17, wherein the emulator partition comprises the proxy and a virtual machine, the virtual machine comprising, for each of a plurality of corresponding hardware devices: a corresponding association with one of one or more application device drivers; a corresponding blocking queue; a corresponding command queue; and a corresponding device thread.

[Clause 19] The system of any one of clauses 17 or 18, wherein the emulator partition comprises a plurality of virtual central processing unit threads, each virtual central processing unit thread being configured to generate control signals in response to blocking signals. [Clause 20] The system of clause 19, wherein each virtual central processing unit thread contains a distinct application device driver.

[Clause 21] The system of any one of clauses 15 or 20, wherein the processor comprises a plurality of cooperating processors. [78] It should be expressly understood that not all technical effects mentioned herein need to be enjoyed in each and every embodiment of the present technology. For example, embodiments of the present technology may be implemented without the user enjoying some of these technical effects, while other embodiments may be implemented with the user enjoying other technical effects or none at all. [79] Some of these operations and signal sending-receiving are well known in the art and, as such, have been omitted in certain portions of this description for the sake of simplicity. The signals can be sent-received using optical means (such as a fibre-optic connection), electronic means (such as using wired or wireless connection), and mechanical means (such as pressure-based, temperature based or any other suitable physical parameter based). [80] Modifications and improvements to the above-described implementations of the present technology may become apparent to those skilled in the art. The foregoing description is intended to be exemplary rather than limiting. The scope of the present technology is therefore intended to be limited solely by the scope of the appended claims.