Patent Description:
Operating systems (OSes) control virtually all of today's networked devices. Everything from personal computers to virtual reality (VR) headsets to Internet of Things (IoT) devices rely an OS to provide a software environment in which application-specific code may be deployed. Yet, devices in the area of embedded systems typically run on a controller or processing chip with a limited amount of memory. With memory and processing resources constrained, the OSes running on embedded systems must be efficient.

Modern OSes must function on numerous disparate devices. Consequently, an OS build is configured to operate devices with various different hardware, such as serial ports, displays, network interfaces, and numerous other components. For example, a laptop will have different hardware than a VR headset or an IoT device. Different hardware components use different drivers. So an OS must be able to support different drivers for different hardware components to be able to across a collection of devices.

Device drivers for a particular client device are traditionally identified by the OS at run time, compile time, or link time. Integrating an OS with client drivers at run-time solutions are flash-, memory-, and instruction-inefficient as extra logic is used to select and configure the appropriate drivers. There are also typically pointer dereferences involved in each driver operation, which may be unnoticeable on personal computers but are impact embedded systems due to processing and memory constraints. Integrating an OS with client drivers at compile time pollutes the hardware-agnostic code of the OS with many hardware-specific references and requires quite a bit of rebuilding for each hardware target. This dramatically reduces OS developer productivity. Integrating an OS with client drivers at link time is a bit more efficient but requires an OS developer to already know the specific device drivers of an intended client device as well as the specific code names and configurations of those device drivers. This is very time-intensive for the developer and requires precision to make sure the correct names of the driver are instantiated and used for linking to the client device. These three ways of integrating OS builds to the hardware of client devices require either a substantial amount of additional code in the OS (which require additional memory and processing) or a knowledge of device drivers beforehand by the developer. The latter becomes untenable as the variety of client devices targeted by the OS increases. <NPL>, relates to using the device tree to describe embedded hardware. As part of the merger of <NUM>-bit and <NUM>-bit PowerPC support in the kernel, the firmware interface was standardized by using an Open Firmware-style device tree for all PowerPC platforms; server, desktop, and embedded. Up to this point, most PowerPC embedded systems were using an inflexible and fragile, board-specific data structure to pass data between the boot loader and the kernel. The move to using a device tree is expected to simplify and generalize the PowerPC boot sequence. The implications of using a device tree in the context of embedded systems is discussed. The current state of device tree support in arch/powerpc, and both the advantages and disadvantages for embedded system support are discussed. <CIT> relates to a method and apparatus for automatically generating, verifying and using software bindings. A function collector extracts functions from a library written in a first computer language in the form of exposed application program interfaces (APIs), and writes identifying information for the functions to a knowledge base. A document collector concurrently extracts human readable text, such as in the form of embedded comments and user manual documentation, and links this text in the knowledge base to the extracted functions. A set of generators operate to generate software language bindings and a user interface to enable a user to activate and review the human readable text using a different, second computer language. A test script generator can automatically validate operation of the software language bindings using verified test data sets. <CIT> relates to a method for generating a customized program logic operable to control hardware devices of a target system and to boot said target system including determining the hardware devices operatively connected with the target system. A list of identifiers of the determined hardware devices is sent to a server system. The server system selects from a set of drivers for each of the device identifiers in the list at least one driver operable to control the identified device to generating a sub-set of said set of drivers. The server system retrieves a core program logic being free of any drivers of the target system and complements the core program logic with said driver sub-set to generate the customized program logic. The customized program logic is then deployed to the target system.

It is the object of the invention is to provide an efficient implementation of hardware specific code in an operating system.

Examples disclosed herein are directed to automatically building an image of an OS for a specific client device, with the particular driver bindings and driver instances needed to link the OS to the particular hardware of the client device. To do so, a device tree of the client device is analyzed to identify the hardware components of the client device. Databases of different hardware source code for various hardware drivers are maintained and used to generate the driver bindings and instances for the hardware of the client device. To do so, the device tree is also analyzed to identify compatibility strings of the various hardware on the client device. The hardware source code is searched for these compatibility strings to see if a driver exists in the databases of hardware source code. If so, the driver is analyzed (e.g., when it is inserted into the database) and used to generate specific driver bindings and driver instances with the actual variable names and configuration parameters of the identified hardware drivers. These driver bindings and driver instances are included in an image of the OS, which may be transmitted to the client device and installed thereon. This ensures that only the hardware drivers needed for the actual hardware on the client device are included in the image of the OS, and that calls between the OS and driver can be optimized (by the compiler and linker during the OS build).

References made throughout this disclosure relating to specific examples and implementations are provided solely for illustrative purposes but, unless indicated to the contrary, are not meant to limit all examples.

The majority of the code in an OS is hardware independent. Developers want to the write most of the OS code once so that it may perform the same way on multiple devices. But these different end devices have different hardware configurations. So there are portions of an OS that that need to be hardware specific. The OS has to link some of its operations to the specific hardware of an end device, which typically involves finding the correct device drivers and then integrating these device drivers with the hardware-independent portions of the OS code.

The disclosed embodiments and examples provide systems, methods, and executable instructions for machine learning the drivers of a client device and automatically instantiating the correct driver bindings for that hardware in a build of the OS for the client device. In some embodiments, the OS code is compiled into an OS compiled object that includes both hardware-independent portions and hardware-specific portions. The hardware-specific portions have various internal and external interfaces that are to be linked with the different hardware of a client device. The disclosed embodiments automatically identify the particular hardware drivers of a given client device from a device tree and create driver bindings for the uncovered hardware drivers of the client device. These driver bindings are instantiated in the OS source code, providing an effective linking of the various OS external and internal interfaces to the specific hardware of the client device. As a result, an image of the OS with the specific linked device drivers for the specific hardware on the client device is created, allowing the client to download a substantially smaller OS build that does not require as much memory to store and run.

Traditionally, the OS source code calls a well-known function name but that function is not provided by the OS so the OS compiled object will not contain a symbol with that name. The disclosed binding generator creates a function with that well-known name that invokes the corresponding function on the driver instance. The hardware-specific compiled object then contains the well-known symbol name. The linker can then make the connection between the two compiled objects when producing the OS image.

In some embodiments, the disclosed embodiments locate and link hardware-specific drivers for the particular hardware of a client device to an OS build. The specific drivers for a client device are automatically learned from a device tree of the client device stored in a database or repository. This is done at build time of the OS, not during run time like some conventional approaches. The "device tree" is an existing description of the hardware residing on the client device, describing the properties/configuration of the hardware itself. In particular, the device tree specifies a compatibility string for each piece of hardware, specifying what driver the hardware is compatible with. Other embodiments utilize the device tree solely on the build machine, without ever having to go to the client device.

Once learned from the device tree, the compatibility string is used to determine which driver to reference in a driver binding for a particular piece of hardware of the client device, and then a driver binding is automatically generated based on the identified driver. For example, a device tree may specify compatibility string "abc,company,UART3620" for a specific universal asynchronous receiver transceiver (UART) manufactured by the fictitious ABC company. Embodiments identify the specific type of UART of the client device using the compatibility string abc,company,UART3620 in the device tree, and use the compatibility string to locate corresponding driver code for the identified hardware in a driver model that includes source code for a collection of different drivers. The driver code for the identified hardware is used to create the driver binding and properly instantiate the driver in the OS build in order to create the image of the OS build for the client device.

The driver bindings that are automatically generated by the disclosed embodiments are concrete implementations with symbol names that a linker program can connect to the hardware-independent OS code. Doing so allows many candidate drivers to be present in the same linked libraries as object file symbol names do not conflict. Also, the OS is able to use the specific names, processes, types, and routines of the hardware drivers. In this vein, embodiments automatically generate driver class instances for the OS build, passing selected configuration data in the device tree to class constructors. In some examples, these constructors are "constexpr" C++ constructors that allow for compile-time object construction that is very device memory-efficient.

The disclosed embodiments and examples save a substantial amount of developer time and memory resources. OS developers no longer have to painstakingly spell out all of the different driver configurations that are either on or anticipated to be used by client devices. Nor does the OS build need to include lengthy lists of driver configurations, which cuts down the amount of memory needed, making the disclosed embodiments well suited for embedded system devices. Instead, device-specific images of the OS are prepared that include the exact drivers for the hardware of the client device, providing an automated way to generate smaller OS images for embedded systems that have limited memory. Also, the disclosed examples save valuable time for OS developers who likely do not know all of the drivers that are included on a new client device-let alone all of the driver configurations. Also, different entities are able to author the OS and the drivers/device tree. For example, a software company may author the OS and a hardware vendor may author the device drivers and device trees for their devices.

For the sake of clarity, the disclosed embodiments and examples are discussed herein in reference to a cloud environment, which may be a third-party operated cloud-computing network, an on-premises IT network of an organization, a combination thereof, or the like. The terms "cloud environment" and "cloud-computing environment," as referenced herein include third-party cloud environments, on-premises IT networks, and any other remote server networks.

Having generally provided an overview of some of the disclosed examples, attention is drawn to the accompanying drawings to further illustrate some additional details. The illustrated configurations and operational sequences are provided for to aid the reader in understanding some aspects of the disclosed examples. The accompanying figures are not meant to limit all examples, and thus some examples may include different components, devices, or sequences of operations while not departing from the scope of the disclosed examples discussed herein. In other words, some examples may be embodied or may function in different ways than those shown.

<FIG> illustrates an example of a client device configured to receive an OS build with hardware driver bindings and instances for resident hardware components in accordance with some of the embodiments disclosed herein. Client device <NUM> includes one or more processing units <NUM>, input/output (I/O) ports <NUM>, a communications interface <NUM>, computer-storage memory (memory) <NUM>, hardware components <NUM>, and a communications path <NUM>-all of which constitute hardware components with drivers and presence in one or more device trees.

Client device <NUM> may take the form any number of computing devices <NUM>, such as laptops, smartphones, tablets, VR headsets, wearables, embedded systems, or the like. In specific embodiments, as indicated by the electronic chip in <FIG>, client device <NUM> is an embedded system, such as, for example but without limitation, a smart sensor, IoT device, application-specific integrated circuit (ASIC), or other device that engineered and programmed for a specific functional purpose. Client device <NUM> is but one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the disclosed embodiments.

The processing unit <NUM> may include any type of ASIC, System on Chip (SoC), microcontroller, controller, microprocessor, analog circuit, or the like for that are programmed to execute computer-executable instructions for implementing aspects of this disclosure. In some examples, the processing unit <NUM> is programmed to execute instructions such as those illustrated in the other drawings discussed herein. For purposes of this disclosure, the terms "processor," "controller," "processing unit," and "control unit" are meant to connote the same thing and are used interchangeably.

Client device <NUM> is equipped with one or more hardware components <NUM>. Hardware components <NUM> refer to the specific hardware that is connected to or resident on client device <NUM>. Examples of hardware components <NUM> include, without limitation, transceivers (e.g., UART); displays (e.g., touch, VR or augmented reality (AR), etc.); peripherals (e.g., stylus, wearable, etc.); sensors (e.g., accelerometer, inertial movement unit (IMU), gyroscope, global positioning system (GPS), magnetometer, etc.); microphones; speakers; or any other hardware. Any combination of hardware may be incorporated in client device <NUM>.

Hardware components <NUM> are configured to operate according to specific hardware drivers (HW drivers) <NUM>. HW drivers <NUM> represent the specific software and firmware instructions for operating the hardware components <NUM>. In some embodiments, source code of HW drivers <NUM> is provided to or made available to OS developers. This source code may be uploaded to a code repository, as discussed in more detail in reference to <FIG>.

As previously discussed, a device tree <NUM> is created for client device <NUM>. Device tree <NUM> specifies the hardware components <NUM> resident on client device <NUM> and, specifically, a compatibility string indicating HW drivers <NUM> for use in operating hardware components <NUM>. For example, a particular UART hardware component <NUM> may have a device tree that specifies the specific type of UART, serial port it provides, registers it uses, clocks it uses, and a compatibility string. The compatibility string provides a list of compatible names that is, in some embodiments, intended to be of decreasing specificity. For example, a device tree compatible list might include "mediatek,uart-mt3620," "mediatek,uart," and "generic-uart," which allows OSes to find the most specific driver they have for that hardware. If the OS does not have a driver for any of those names, the OS is not compatible for the hardware.

This type of information may be included for every one of the hardware components <NUM> in device tree <NUM>, so, for instance, a display, sensor, etc. As discussed in more detail below, design tree <NUM> is used by an OS build service to automatically generate the specific code to tailor an OS build to the client device <NUM> by using the specific calls, names, types, routines, and other software or firmware of the HW drivers <NUM>.

While some embodiments use the device tree <NUM>, other embodiments use different formats that describe the hardware of a system or computing device. For the sake of clarity, embodiments reference use of a device tree <NUM>, but other lists of hardware may be alternatively used and are fully contemplated in the discussions herein of device trees.

In some embodiments, the manufacturer of client device <NUM> creates device tree <NUM>. Alternatively, third parties may generate the device tree <NUM>. Device tree <NUM> may be privately or publicly shared with an OS developer. For instance, OS developers working on a build of the WINDOWS® OS provided by the MICROSOFT CORPORATION® headquartered in Redmond, Washington, may receive device trees <NUM> for myriad client devices <NUM> to tailor different builds of WINDOWS® therefor.

I/O ports <NUM> provider internal and external connections for the hardware components <NUM>. Hardware components <NUM> use the I/O ports <NUM> to operate externally and internally.

Communications interface <NUM> allows software and data to be transferred between client device <NUM> and external devices over a network <NUM>. Examples of communications interface <NUM> may include a modem, a network interface (such as an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, a BLUETOOTH® transceiver, radio frequency (RF) transceiver, a near-field communication (NFC) transmitter, or the like. Software and data transferred via the communications interface <NUM> are in the form of signals that may be electronic, electromagnetic, optical or other signals capable of being received by communications interface <NUM>. Such signals are provided to the communications interface <NUM> via the communications path (e.g., channel) <NUM>. This communications path <NUM> carries the signals and may be implemented using a wired, wireless, fiber optic, telephone, cellular, radio frequency RF, or other communication channel.

Network <NUM> may include any computer network or combination thereof. Examples of computer networks configurable to operate as network <NUM> include, without limitation, a wireless network; landline; cable line; digital subscriber line (DSL): fiber-optic line; cellular network (e.g., <NUM>, <NUM>, <NUM>, etc.); local area network (LAN); wide area network (WAN):, metropolitan area network (MAN); or the like. The network <NUM> is not limited, however, to connections coupling separate computer units. Rather, the network <NUM> may also comprise subsystems that transfer data between servers or computing devices. For example, the network <NUM> may also include a point-to-point connection, the Internet, an Ethernet, an electrical bus, a neural network, or other internal system. Such networking architectures are well known and need not be discussed at depth herein.

Computer-storage memory <NUM> includes any quantity of memory devices associated with or accessible by the client device <NUM>. The computer-storage memory <NUM> may take the form of the computer-storage media references below and operatively provide storage of computer-readable instructions, data structures, program modules and other data for the client device <NUM> to store and access instructions configured to carry out the various operations disclosed herein. The computer-storage memory <NUM> may include memory devices in the form of volatile and/or nonvolatile memory, removable or non-removable memory, data disks in virtual environments, or a combination thereof. And computer-storage memory <NUM> may include any quantity of memory associated with or accessible by the client device <NUM>. Examples of client device <NUM> include, without limitation, random access memory (RAM); read only memory (ROM); electronically erasable programmable read only memory (EEPROM); flash memory or other memory technologies; CDROM, digital versatile disks (DVDs) or other optical or holographic media; magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices; memory wired into an analog computing device; or any other computer memory.

The computer-storage memory <NUM> may be internal to the client device <NUM> (as shown in <FIG>), external to the client device <NUM> (not shown), or both (not shown). Additionally or alternatively, the computer-storage memory <NUM> may be distributed across multiple client devices <NUM> and/or servers, e.g., in a virtualized environment providing distributed processing. For the purposes of this disclosure, "computer storage media," "computer-storage memory," "memory," and "memory devices" are synonymous terms for the computer-storage media <NUM>, and none of these terms include carrier waves or propagating signaling.

In some examples, the computer-storage memory <NUM> stores executable computer instructions for an operating system (OS) image <NUM> and various software applications <NUM>. The OS image <NUM> may be any OS designed to control the functionality of client device <NUM>, including, for example but without limitation: WINDOWS® developed by the MICROSOFT CORPORATION® of Redmond, Washington; MAC OS® developed by APPLE, INC. ® of Cupertino, California; ANDROID™ developed by GOOGLE, INC. ® of Mountain View, California; open-source LINUX®; or the like. In some embodiments, the OS image <NUM> is of an embedded OS for running on an embedded system. Embedded OSes are typically designed to be resource-efficient, including functions that only operate on RAM or ROM of client device <NUM>, which may be the only resident memory <NUM> onboard. In such embodiments, the embedded system OS may be a real-time OS (RTOS).

In some embodiments, the OS image <NUM> is specifically tailored for the client device <NUM> though the building and linking operations discussed below. Once built, the OS image <NUM> includes various hardware-independent code <NUM> and hardware-specific code <NUM>. The hardware-independent code <NUM> comprises instructions or portions of the corresponding OS that are coded the same way regardless of the hardware components <NUM> of client devices <NUM>. For example, hardware-independent operations <NUM> may include different ways to open objects, queue different operations, package data transmissions, or any other operation that does not vary-at least in code-by the particular hardware components <NUM>. On the other hand, the hardware-specific code <NUM> comprises different code (e.g., types, names, functions, configurations) depending on the hardware components <NUM> that are present. In other words, the hardware-specific operations <NUM> change from image to the image of the OS based on the driver information of the HW drivers <NUM>, e.g., clocks, registers, compatibility strings, ports, etc..

In some embodiments, the hardware-specific code <NUM> is coded according to the HW drivers <NUM> of the hardware components <NUM>. This coding of the hardware-specific code <NUM> changes in different OS images <NUM> residing on client devices <NUM> of different hardware configurations. For example, a display form ABC company may have a different HW driver <NUM> with different variables, routines, configurations, etc. than a display from XYZ company. So the hardware-specific code <NUM> may include different code for controlling the XYZ display according to its HW driver <NUM> than the code used for controlling the ABC display according to its HW driver <NUM>.

In this vein, the OS image <NUM> includes various driver bindings <NUM> and driver instances <NUM> that are specifically coded according to the HW drivers <NUM>. As discussed in more detail below, source code of the HW drivers <NUM> is analyzed to obtain the specific coding parameters (e.g., variables, functions, configurations, operations, routines, etc.) used by the HW drivers <NUM>, driver bindings <NUM> with the obtained specific coding is generated and instantiated (driver instances <NUM>) during a build of the OS. Then, an image of that driver-specific build of the OS is generated, creating the OS image <NUM> that is eventually downloaded to client device <NUM>.

<FIG> is a block diagram of a networking environment <NUM> for generating the OS image <NUM> with the hardware-specific code <NUM> for the hardware components <NUM> of the client device <NUM>, according to some of the disclosed embodiments. Networking environment <NUM> involves the client device <NUM> for receiving the OS image <NUM>, one or more servers <NUM>, and computer <NUM> being used by a developer <NUM> of the OS, all of which are connected to the network <NUM>. Computer <NUM> may be a PC, laptop, or other computer that the developer <NUM> uses to build the OS image <NUM> for the client device <NUM> using the disclosed services in a cloud environment being hosted by servers <NUM>.

The servers <NUM> may be any type of server or remote computing device, either as a dedicated, relational, virtual, private, public, hybrid, or other cloud-based node. The servers include or have access to one or more processors <NUM>, communications interfaces <NUM>, and computer-storage memory <NUM>, similar to the same-labeled components in <FIG>. Specifically, the servers <NUM> include or have access to various processors <NUM>, I/O ports <NUM>, a communications interface <NUM>, computer-storage memory <NUM>, I/O components <NUM>, and a communications path <NUM>. The processors <NUM> supports server an OS that underlies the execution of software, applications, and computer programs thereon. In one instance, the computing unit is configured with tangible hardware elements, or machines, that are integral, or operably coupled, to the servers 201a,b to enable each device to perform a variety of processes and operations. The I/O ports <NUM>, communications interface <NUM>, computer-storage memory <NUM>, I/O components <NUM>, and communications path <NUM> may operate in the same manner as the similarly referenced components of <FIG>. Server topologies and processing resources are generally well known to those in the art, and need not be discussed at length herein, other than to say that any server configuration may be used to execute the OS component server discussed below.

An operating system build (OS build) service <NUM> is stored in the memory <NUM> of the servers <NUM> and executable by the processors <NUM>. The OS build service <NUM> may be implemented partly or wholly as software code or through firmware. In particular, the OS build service <NUM> includes executable code instructions for a compiler <NUM>, a binding generator <NUM>, a linker <NUM>, and a HW model generator <NUM>. Additionally, the OS build service <NUM> includes or has access to a device trees database <NUM>, a hardware driver source code (driver source code) database <NUM>, and a hardware model (HW model) database <NUM>.

The device trees database <NUM> stores various device trees <NUM> for numerous client devices <NUM>. As referenced above, the device trees <NUM> specify the hardware components <NUM> on the various client devices <NUM>. Device trees <NUM> are specific to individual client devices <NUM>. For instance, an IoT device manufactured by ABC company has a different device tree <NUM> than a tablet manufactured by XYZ company. In some embodiments, the device trees <NUM> in the device trees database <NUM> are generated and shared as open-source code-e.g., through LINUX®. Alternatively, the device trees <NUM> are provided privately to an OS manufacturer (i.e., the company releasing an OS), which stores the device trees <NUM> securely. For example, numerous companies that manufacture computers and embedded systems may share device trees <NUM> with the MICROSOFT CORPORATION® that offers the WINDOWS® OS. In operation, each device tree <NUM> defines a compatibility string that references a name assigned to the HW driver <NUM> for a particular hardware component <NUM>.

The driver source code <NUM> database stores source code of the various HW drivers <NUM> (HW driver source code <NUM>). This HW driver source code 230may be created and provided by the manufacturer of the hardware components <NUM>. For example, a display manufacturer provides the appropriate HW driver <NUM> for its display, either publicly or privately to the OS manufacturer. In particular, the HW driver source code <NUM> includes the exact types, variables, names, routines, operations, and hardware configurations that the HW drivers <NUM> use to control their respective hardware components <NUM>. The HW driver source code <NUM> is one of the HW drivers <NUM> used to run the hardware components <NUM>.

The HW models database <NUM> stores driver models <NUM> for the various HW drivers <NUM> in all, a subset, or at least one of the hardware components <NUM> of the client devices <NUM> through analysis of the device trees <NUM> and the driver source code <NUM>. An example of a driver model <NUM> is shown in <FIG> below. For each client device <NUM>, the model generator <NUM> analyzes its device tree <NUM> to identify the compatibility string of the HW driver <NUM>. The compatibility string <NUM> is searched for in the driver source code <NUM> to identify where the specific HW driver <NUM> code is located. The model generator <NUM> analyzes the driver source code <NUM> where the compatibility string <NUM> is found, parsing out (or identifying) the specific class <NUM>, variable name <NUM>, and driver configuration parameters <NUM> and generates the driver model <NUM> for that HW driver <NUM> from the driver source code <NUM>. In some embodiments, the driver model <NUM> includes the compatibility string, the type of driver (e.g., a UART driver, display, etc.), the specific name assigned to the HW driver <NUM> in the driver source code <NUM>, and various driver parameters specific to the driver (e.g., operands the HW driver <NUM> driver requires). In some embodiments, the driver model <NUM> is stored as a TXT file.

The model generator <NUM> applies various heuristics, via code, to parse the driver source code <NUM> of a HW driver <NUM> for the driver model <NUM>. One particular heuristic-based code is the open-source code LIBCLANG. Other heuristic-based algorithms may be applied that identify the specific variables, operations, operands, functions, types, routines, and other code parts that are included in the driver models <NUM>.

The OS build service <NUM> uses the compiler <NUM>, binding generator <NUM>, and linker <NUM> to take source code of an OS (the OS source code <NUM>) and create the OS image <NUM> that is specifically tailored for the client device <NUM>. To do so, the compiler <NUM> compiles the OS source code <NUM> into a compiled OS object <NUM>. The compiled OS object <NUM> includes the previously discussed hardware-independent code <NUM>. The linker <NUM> integrates a hardware-independent compiled OS object and a hardware-specific compiled object to produce the OS image <NUM>. These driver-specific operations and variables constitute external interfaces that are to be linked with the different hardware components <NUM> of the client device <NUM>. The linker <NUM> automatically identifies these external interfaces, and the binding generator <NUM> creates the driver bindings <NUM> and driver instances <NUM> that link the compiled OS object <NUM> to the hardware components <NUM> of the client device <NUM>.

The OS build service <NUM> allows the OS developer <NUM> to create the OS image <NUM> with the driver bindings <NUM> and the driver instances <NUM> from a build of the OS, referenced as the OS source code <NUM>. The compiler <NUM> compiles the OS source code <NUM> into a compiled OS object <NUM> that includes the previously discussed hardware-independent code <NUM> and the hardware-specific code <NUM>. The OS compiled object <NUM> is then analyzed by the linker <NUM> to identify where the driver bindings <NUM> are needed.

The binding generator <NUM> analyzes the device tree <NUM> to identify the various hardware components <NUM> of the client device <NUM>. For each hardware component <NUM>, the binding generator <NUM>, the binding generator identifies or locates a compatibility string that specifies the name of the HW driver <NUM> given by the driver's developer. In some embodiments, the binding generator <NUM> searches for the compatibility string in the HW driver source code <NUM> of the driver source code database <NUM>.

As mentioned above, traditional OS source code calls a well-known function name but that function is not provided by the OS so the OS compiled object will not contain a symbol with that name. The binding generator <NUM> creates a function with that well-known name that invokes the corresponding function on the driver instance. The hardware-specific compiled object then contains the well-known symbol name. The linker <NUM> may then make the connection between the two compiled objects when producing the OS image.

Additionally or alternatively, the binding generator <NUM> may search for the compatibility string in the HW models <NUM> of the HW model database <NUM>. Embodiments may use either the HW driver source code <NUM> or the driver models <NUM> to generate the driver bindings <NUM> and driver instances <NUM>. If the compatibility string is not found in either the HW driver source code <NUM> or the driver models <NUM>, an error is be returned. If the compatibility string is found, the binding generator <NUM> automatically generates the driver binding <NUM> and the driver instances <NUM> from the driver source code <NUM> with the specific compatibility string.

<FIG> illustrates UI diagrams of a driver binding <NUM> being generated from HW driver source code <NUM> and a device tree <NUM> of a client device <NUM>, according to some of the disclosed embodiments. The illustrated example shows the driver <NUM> being generated for a particular UART of the client device <NUM> manufactured by MEDIATEK® with a product identifier of UART MT3620 M4. Only one driver binding <NUM> is shown, but the disclosed embodiments generate driver bindings <NUM> for all, or at some, of the hardware components <NUM> of the client device <NUM>.

In operation, the binding generator <NUM> analyzes the device tree <NUM> to locate and identify a compatibility string <NUM> that has been specifically assigned to the UART hardware component <NUM>, either by the manufacturer (e.g., MEDIATEK®) or a third party that developed the corresponding HW driver <NUM>. In the depicted example, the compatibility string <NUM> was given the name "mediatek,mt3620-uart. " The device tree <NUM> also specifies various driver configurations <NUM>, such as the particular register being used, clock parameters, version compatibility, whether the hardware component <NUM> is enabled or not in an OS, or other configurations.

The binding generator <NUM> searches for the compatibility string <NUM> in the HW driver source code <NUM> to identify the relevant code of the HW driver <NUM> for the UART hardware component <NUM>. Once the compatibility string <NUM> is located in the driver source code <NUM>, the binding generator <NUM> identifies the specific function calls, variables, names, and configurations specified for the UART hardware component <NUM> in the HW driver source code <NUM>. In the depicted example, the hardware type <NUM> is identified as an M4 UART, and a compatibility string <NUM> provides the name, mediatek,mt3620-uart, used to search the driver source code <NUM> for the correct HW driver <NUM> of the UART hardware component <NUM>. The illustrated HW driver source code <NUM> shows the HW driver <NUM> found in the driver source code database <NUM> with the compatibility string <NUM>. This driver source code <NUM> is then analyzed by the binding generator <NUM> and used to automatically build the driver binding <NUM>.

The binding generator <NUM> automatically generates the driver binding <NUM> using the HW driver source code <NUM>. In some examples, the HW driver source code <NUM> for the UART hardware component <NUM> includes a class <NUM> and variable name <NUM> that are used, or expected, by the HW driver source code <NUM>. Additional driver configuration parameters <NUM> may be specified as well. Though not shown, additional driver configuration parameters <NUM> may include specific functions for setting and baud rates. These driver configuration parameters <NUM> may be taken from the HW driver source code <NUM> or HW models <NUM> that are built therefrom. An example driver model <NUM> is shown in <FIG>. As shown, the same class <NUM> and variable name <NUM> from the HW driver source code <NUM> are populated in the driver binding <NUM>, and different function calls are created for the driver configuration parameters <NUM>, setting and getting preferred baud rates. Thus, the driver binding <NUM> is generated through analyzing the device tree <NUM> for the compatibility string <NUM>, using the compatibility string <NUM> to identify the correct HW driver source code <NUM>, and creating the driver being <NUM> using the HW driver source code <NUM>.

<FIG> illustrates UI diagrams of a driver instance <NUM> being generated from HW driver source code <NUM> and a device tree <NUM> of a client device <NUM>, according to some of the disclosed embodiments. The binding generator <NUM> starts with a list of drivers that need to be located in the device tree <NUM>. In the depicted example, "chosen/azsphere,debug-uart" is in that list. For each driver, the binding generator <NUM> follows a pointer (phandle in device tree <NUM>) to the specific hardware node (m4_uart). The binding generator <NUM> uses the compatible property of that node to locate the appropriate driver model (or source code if not using a model). The binding generator <NUM> reads from the HW model <NUM> a description of the parameters required by the driver class' constructor (310r-w). For each required parameter, the binding generator <NUM> looks for a suitable value in the device tree. A relative or absolute location in the device tree may be specified by the driver author (see the AZSPHERE_CONSTRUCTOR_ARG_DT_SOURCE macro in <FIG>). If no parameter path is supplied, the binding generator <NUM> looks for a property with the same name as the parameter on the device tree <NUM> node for this hardware device. In <FIG>, the xtal_frequency parameter has been given a specified relative search path (follow the 'clocks' property to a different node and use the 'clock_frequency' property found there). The 'reg' parameter, in contrast, has no specific path supplied so it is filled in with the value of the 'reg' property of the uart@<NUM> node.

When a suitable parameter value is found in the device tree <NUM>, the binding generator <NUM> creates a variable or constant to store the value (e.g. the uart_21040000_xtal_frequency variable in the bottom frame of <FIG>). Once all parameters have had their values stored in generated variables or constants, the binding generator <NUM> emits a call to the driver class constructor, passing those variables or constants (e.g. second to last line in <FIG>). This, in turn, creates an instance of the HW driver. In this embodiment, the driver instance is passed to another constexpr class constructor (last line).

<FIG> illustrate an example driver model <NUM> built from HW driver source code <NUM>, according to some of the disclosed embodiments. The driver model <NUM>, which is generated by the model generator <NUM>, includes various driver configuration parameters 310a-w. In some embodiments, the driver configuration parameters 310a-w are parsed from the HW driver source code <NUM>, identified by the compatibility string <NUM> in the device tree <NUM> of the client device <NUM>. The driver model <NUM> may be stored as a text file (. TXT) file that may be searched or tagged to identify the various driver configuration parameters 310a-w. Once generated, the binding generator <NUM> may use the driver model <NUM> in the generation of the driver bindings <NUM> and/or driver instances <NUM>.

Again, the model generator <NUM> applies various heuristics, via code, to parse the driver source code <NUM> of the HW driver <NUM> to create the driver model <NUM>. One particular heuristic-based code is open source LIBCLANG. Other heuristic-based algorithms may be applied that identify the configuration parameters 310a-w for the driver model <NUM>.

<FIG> illustrates a flowchart diagram showing a computer-executed workflow <NUM> for generating an image of an OS that is specifically tailored for the hardware of a client device, according to some of the disclosed embodiments. As shown at <NUM>, a device tree of the client device is accessed. From the device tree, the hardware of the client device is identified as well as the compatibility strings for each hardware component, as shown at <NUM>. A repository or database of hardware source code is then searched to see if the compatibility strings of the hardware components are found, as shown at <NUM>. If not, an error in the build process of the specific image of the OS is returned, as shown at <NUM>. Such an error may be provided to an OS developer.

On the other hand, if the compatibility string of a first hardware component is found in the hardware source code, various hardware variable names and configuration parameters are identified in the hardware source code, as shown at <NUM>. Configuration parameters are read from the hardware driver model of the first hardware component, as shown at <NUM>. The device tree for the first hardware component is checked to see whether the required parameters are specified, as shown at <NUM>. If the required parameters are not present, the build fails, as shown at <NUM>. If the required parameters are present, driver bindings and driver instances may then be generated using the identified variable names and configuration parameters, as shown at <NUM> and <NUM>. This sequence is repeated for each of the hardware components in the device tree, as shown at decision box <NUM>.

After all of the hardware components have been bound and instantiated, the image of the OS for the client device is created, as shown at <NUM>. This image of the OS includes the driver bindings and driver instances generated through the disclosed techniques. And the image of the OS may then be transmitted to the client device for installation thereon, as shown at <NUM>.

<FIG> illustrates a flowchart diagram showing a computer-executed workflow <NUM> for generating a driver model, according to some of the disclosed embodiments. As shown at <NUM>, the hardware source code for a hardware driver is accessed. Heuristics-based code (e.g., LIBCLANG) is used to parse the different parts of the hardware source code, identifying which ones are variables, operations, functions, and configuration parameters, as shown at <NUM>. If no configuration parameters for the hardware (e.g., 310a-w in <FIG>), zero parameters are described, as shown at <NUM>. But if configuration parameters are located, the configuration parameters are used to create a driver model for the specific hardware component, as shown at <NUM>. This driver model may then be stored in a HW models database, as shown at <NUM>.

Some examples are directed to a method for automatically building driver bindings for hardware components to include in an OS for a client device. The method includes: accessing a device tree for the client device; identifying one or more hardware components of the client device from the device tree; for a first hardware component, locating a first compatibility string in the device tree; identifying first hardware driver source code for the first hardware component using the first compatibility string, the first hardware driver source code comprising one or more variable names and specifying function calls for a first hardware driver associated with the first hardware component; automatically generating a first driver binding based on the first hardware driver source code, wherein the first driver binding includes the one or more variable names and function calls specified in the first hardware driver source code; generating a driver instance based on the first driver binding, the driver instance comprising driver configuration parameters identified for the first hardware component from the device tree, wherein the driver instance is generated by emitting a call to a driver class constructor; and generating an image of the OS comprising the first driver binding and the driver instance for supply to the client device.

In some embodiments, the first compatibility string is set by a manufacturer of the client device.

Some embodiments additionally include identifying the one or more hardware components of the client device from the device tree; for a second hardware component of the one or more hardware components, locating a second compatibility string in the device tree; identifying other hardware driver source code for the second hardware component using the first compatibility string, the other hardware driver source code comprising a variable name for a second hardware driver associated with the second hardware component; automatically generating a second driver binding based on the other hardware driver source code, wherein the second driver binding includes the variable name in the second hardware driver source code; and adding the second driver binding to the image of the OS.

Some embodiments also include transmitting the image of the OS to the client device.

Some embodiments also include: identifying driver configuration parameters of at least one of the one or more hardware components from the first hardware driver source code; generating a driver instance based on the first driver binding, the driver instance comprising the driver configuration parameters; and adding the driver instance to the image of the OS.

Some embodiments also include adding the driver instance to the image of the OS.

In some embodiments, the first driver binding is generated after compilation of the OS.

In some embodiments, the first driver binding is generated without user intervention.

In some embodiments, the first driver binding is generated by one or more VMs in a cloud environment.

Some embodiments also include installing the image of the OS comprising the first driver binding on at least one of an ASIC, a microcontroller, a microprocessor, or an analog circuit on the client device.

Some embodiments also include executing a heuristic-based model on the first hardware driver source code to create a driver model.

In some embodiments, the heuristic-based model may be open-source code LIBCLANG.

Other embodiments are directed to a system configured for automatically building an OS specifically for a client device. The system includes: computer memory embodied with one or more databases storing a plurality of hardware driver source code and device trees; and one or more processors programmed to: access a device tree for the client device, identify one or more hardware components of the client device from the device tree, for a first hardware component, locate a first compatibility string in the device tree, identify first hardware driver source code for the first hardware component using the first compatibility string, the first hardware driver source code comprising one or more variable names and function names for a first hardware driver associated with the first hardware component, automatically generate a first driver binding based on the hardware driver source code, wherein the first driver binding includes the one or more variable names and function names in the hardware driver source code;
generate a driver instance based on the first driver binding, the driver instance comprising driver configuration parameters identified for the first hardware component from the device tree, wherein the driver instance is generated by emitting a call to a driver class constructor; and generate an image of the OS comprising the first driver binding and the driver instance for supply to the client device.

In some embodiments, the one or more processors are further programmed to: identify the one or more hardware components of the client device from the device tree; for a second hardware component of the one or more hardware components, locate a second compatibility string in the device tree; identify other hardware driver source code for the second hardware component using the second compatibility string, the other hardware driver source code comprising a variable name for a second hardware driver associated with the second hardware component, automatically generate a second driver binding based on the second hardware driver source code, wherein the second driver binding includes the variable name in the second hardware driver source code; and add the second driver binding to an image of the OS.

Some embodiments also include installing the image of the OS on the client device, wherein the client device comprises an embedded system.

Some embodiments also include executing a heuristic-based model on the first hardware driver source code to create a driver model.

Other embodiments are directed to one or more computer-storage memory embodied with computer-executable instructions for building an image of an OS specific for the hardware of a client device. The memory comprising instructions for: accessing a device tree for the client device; identifying one or more hardware components of the client device from the device tree; for a first hardware component, locating a compatibility string in the device tree; identifying hardware driver source code for the first hardware component using the compatibility string, the hardware driver source code comprising one or more variable names and specifying function calls for a hardware driver associated with the first hardware component; automatically generating a driver binding based on the hardware driver source code, wherein the driver binding includes the one or more variable names and function calls specified in the hardware driver source code; generating a driver instance based on the driver binding, the driver instance comprising driver configuration parameters identified for the first hardware component from the device tree, wherein the driver instance is generated by emitting a call to a driver class constructor; and generating the image of the OS comprising the driver binding and the driver instance.

Some embodiments also include instructions for transmitting the image of the OS to the client device for installation thereon.

In some embodiments, the compatibility string comprises a variable name assigned by a manufacturer of the first hardware component.

The examples and embodiments disclosed herein may be described in the general context of computer code or machine-useable instructions, including computer-executable instructions such as program components, being executed by a computer or other machine, such as a personal data assistant or other handheld device. Generally, program components including routines, programs, objects, components, data structures, and the like, refer to code that performs particular tasks, or implement particular abstract data types. The discloses examples may be practiced in a variety of system configurations, including personal computers, laptops, smart phones, embedded systems, IoT devices, mobile tablets, hand-held devices, consumer electronics, specialty computing devices, etc. The disclosed examples may also be practiced in distributed computing environments where tasks are performed by remote-processing devices that are linked through a communications network.

By way of example and not limitation, computer readable media comprise computer storage media devices and communication media. Computer storage media devices include volatile and nonvolatile, removable and non-removable memory implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or the like. Computer storage media devices are tangible and mutually exclusive to communication media. Computer storage media devices are implemented in hardware and exclude carrier waves and propagated signals. Computer storage media devices for purposes of this disclosure are not signals per se. Example computer storage media devices include hard disks, flash drives, solid-state memory, phase change random-access memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In contrast, communication media typically embody computer readable instructions, data structures, program modules, or the like in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media.

The order of execution and performance of the operations in examples of the disclosure illustrated and described herein are not essential and may be performed in different sequential manners in various examples.

Claim 1:
A method for automatically building driver bindings (<NUM>) for hardware components (<NUM>) to include in an operating system, OS, for a client device (<NUM>), the method comprising:
accessing (<NUM>) a device tree (<NUM>) for the client device;
identifying (<NUM>) one or more hardware components of the client device from the device tree;
for a first hardware component, locating (<NUM>) a first compatibility string (<NUM>) in the device tree;
identifying (<NUM>) first hardware driver source code (<NUM>) for the first hardware component using the first compatibility string, the first hardware driver source code comprising one or more variable names (<NUM>) and specifying function calls for a first hardware driver (<NUM>) associated with the first hardware component;
automatically generating (<NUM>) a first driver binding based on the first hardware driver source code, wherein the first driver binding includes the one or more variable names and function calls specified in the first hardware driver source code;
generating (<NUM>) a driver instance (<NUM>) based on the first driver binding, the driver instance comprising driver configuration parameters (<NUM>) identified for the first hardware component from the device tree, wherein the driver instance is generated by emitting a call to a driver class constructor; and
generating (<NUM>) an image (<NUM>) of the OS comprising the first driver binding and the driver instance for supply to the client device.