Uniform Driver Interface: Difference between revisions

[unchecked revision]

← Older edit

Content deleted Content added

VisualWikitext

Revision as of 17:39, 4 June 2013 view source osdev>Gravaera I don't see a need to explain IPC message block formats, opaque handles, etc in an introductory article; Please file any complaints on the Talk page. ← Older edit		Latest revision as of 04:58, 9 June 2024 view source Xtex (talk \| contribs) Interface administrators, Administrators 977 edits m Bot: Replace deprecated source tag with syntaxhighlight
(10 intermediate revisions by 2 users not shown)
Line 30: * Not at all viable for "casual" projects: requires a significant amount of foreknowledge and prior work. ==Core components of UDI Drivers== ~~==Description==~~ [[Image:Core_spec-8.gif‎\|left\|frame\|alt=Environment\|High level view of UDI environments]] Line 42: ===Modules=== A module is essentially a single executable code object. Specifically, drivers can be broken into multiple executables. A large driver that may only need to load certain components and may not need all of its code in memory all the time may be implemented as a multi-module driver. This partitioning of the driver code into modules is up to the driver vendor of course. Most UDI drivers are expected to be single-module drivers, but complex drivers such as graphics card drivers, etc may be best implemented as multi-module drivers. For example, if a graphics driver exports an OpenGL 3D API along with a Direct3D API, it is very likely that both front-ends have a lot of code behind them that would occupy a lot of memory should both be loaded. Most kernels will use ''either'' OpenGL ''or'' Direct3D, so if such a graphics driver was to split its OpenGL and Direct3D implementations into separate modules, this would enable kernels loading that driver to avoid allocating memory for the code and data for the API it isn't using. ===Regions=== Line 59: ===Metalanguages=== Main article: [[ User:Gravaera/UDI_Metalanguages \| Metalanguages ]] Metalanguages define extensions to the core specification for various purposes, and can also be used to define custom IPC protocols between modules/regions. An example of a case where a custom protocol may be needed is where, for example, a network card driver has a "'''Control'''" region which takes commands from the kernel for power management ("Go to sleep", "prepare to shutdown", etc), and then it has a '''Send'''() region and '''Receive'''() region, which handle its send() and receive() functions respectively.▼ ▲Metalanguages define extensions to the core specification for various purposes, and can also be used to define custom IPC ~~protocols~~protocol APIs between modules/regions. An example of a case where a custom protocol API may be needed is where, for example, a network card driver has a "'''Control'''" region which takes commands from the kernel for power management ("Go to sleep", "prepare to shutdown", etc), and then it has a '''Send'''() region and '''Receive'''() region, which handle its send() and receive() functions respectively. It follows naturally that if the driver receives a "Go to sleep" command from the kernel on its Control region, it would need to send messages to its Send and Receive regions to cause them to cease operation. There is no generic IPC_Send() function defined for IPC across UDI channels -- all IPC must be done according to the protocols APIs defined by a Metalanguage, whether standardized by the UDI spec, or custom-defined. Thankfully, driver writers do not need to define custom protocols for every such case where they want to simply send custom messages between regions: the UDI Core specification defines a "'''Generic I/O Metalanguage'''" IPC protocol which covers a wide range of generic IPC needs and can be extended with custom messages as desired.▼ ▲It follows naturally that if the driver receives a "Go to sleep" command from the kernel on its Control region, it would need to send messages to its Send and Receive regions to cause them to cease operation. There is no generic IPC_Send() function defined for IPC across UDI channels -- all IPC must be done according to the protocols APIs defined by a Metalanguage, whether standardized by the UDI spec, or custom-defined. Thankfully, driver writers do not need to define custom protocols for every such case where they want to simply send custom messages between regions: the UDI Core specification defines a "'''Generic I/O Metalanguage'''" IPC protocol API which covers a wide range of generic IPC needs and can be extended with custom messages as desired. Apart from IPC protocols, Metalanguages also cover extensions to the core specification. For example, the already-defined UDI Bus/Bridge Metalanguage can be extended to support new buses as needed; PCI bus drivers, ISA bus drivers, etc do not all need new Metalanguages, because UDI has defined a core UDI Bus/Bridge Metalanguage. This core UDI Bus/Bridge Metalanguage can be extended using Bus/Bridge Metalanguage extensions specific to each bus. This is a case where a Metalanguage is already defined by the UDI Standard, and that metalanguage itself is extended as needed for each bus.▼ ▲Apart from APIs/IPC protocols, Metalanguages also cover extensions to the core specification. For example, the already-defined UDI Bus/Bridge Metalanguage can be extended to support new buses as needed; PCI bus drivers, ISA bus drivers, etc do not all need new Metalanguages, because UDI has defined a core UDI Bus/Bridge Metalanguage. This core UDI Bus/Bridge Metalanguage can be extended using Bus/Bridge Metalanguage extensions specific to each bus. This is a case where a Metalanguage is already defined by the UDI Standard, and that metalanguage itself is extended as needed for each bus. Entirely new Metalanguages can also be created where necessary; for example, an SCSI Host Bus Adapter is not really a bus, but it is an I/O Microcontroller device that acts as a parent device to SCSI devices (mostly disks). It looks like a bus, but isn't really a bus, and is better handled with an IPC protocol and API of its own. So the UDI specification defines an SCSI Host Bus Adapter Metalanguage which manages communication (IPC) between SCSI Peripheral Devices (disks) and SCSI Host Bus Adapters. On any given motherboard, a commonly seen arrangement may be as follows in the ASCII art below. The SCSI HBA is not a bus, and the IPC communication between SCSI disks and the SCSI HBA cannot be constrained to follow the same format as communication between a bus and its child devices. This is a case where a new Metalanguage is a good idea.▼ ▲Entirely new Metalanguages can also be created where necessary; for example, an SCSI Host Bus Adapter is not really a bus, but it is an I/O Microcontroller device that acts as a parent device to SCSI devices (mostly disks). It looks like a bus, but isn't really a bus, and is better handled with an IPC protocol and API of its own. So the UDI specification defines an SCSI Host Bus Adapter Metalanguage API which manages communication (IPC) between SCSI Peripheral Devices (disks) and SCSI Host Bus Adapters. On any given motherboard, a commonly seen arrangement may be as follows in the ASCII art below. The SCSI HBA is not a bus, and the IPC communication between SCSI disks and the SCSI HBA cannot be constrained to follow the same format as communication between a bus and its child devices. This is a case where a new Metalanguage API for communication is a good idea. As an honourable mention, it would also have been possible to just use the UDI Generic I/O Metalanguage for communication between the SCSI disks and their parent SCSI HBA -- the Generic I/O Metalanguage is equally adequate for that purpose as well. <~~source~~syntaxhighlight lang="text"> RootNode \|- PCI-Bus-0 Line 80 ⟶ 82: \| +- PCI-Bus-2 </syntaxhighlight> ~~</source>~~ Metalanguages are essentially UDI IPC Channel protocol definitions or API definitions, and definitions of extensions to the core specification. Hence the name: Meta-''LANGUAGES''. ~~===Configuration===~~ ==Driver configuration== There's a special configuration method for static properties of UDI drivers using a file called udiprops.txt. This file is distributed independently in each driver package for source code distributions and linked into a special section (called .udiprops) for binary distributions. Line 138 ⟶ 139: Of course, udiprops.txt can be a lot more complex than this, I only wanted you to see what one looks like. You should check the specification for all compile options, statements and configuration options. ==~~Initial~~Programming ~~state~~Model== All UDI function calls are asynchronous in nature; this means that they implicitly do not block. A ''compliant'' UDI driver will always be implicitly non-blocking. Whether or not the ''host kernel'' supports non-blocking programming models is up to that kernel, and for any particular kernel, it may be necessary to use locking, mutexes and blocking. Naturally, for a kernel that fully supports a non-blocking, asynchronous model, UDI will simply scale seamlessly. UDI drivers, because of their asynchronous nature, behave like servers to a large extent and they have very good throughput, owing to the fact that the driver itself will only block if the host kernel imposes a limitation on it. For a host kernel which does not have scaling limitations, UDI drivers will innately also scale without limitations -- the throughput of a ''compliant'' UDI driver is dependent solely on the limitations of the host kernel. Drivers are relocatable objects files, they have no entry points. UDI drivers have only one global variable, udi_init_info that describes the primary module (and perhaps secondary modules), its primary region (and perhaps the secondary regions that it and the other modules have) and what control blocks it requests. udi_init_info is of type udi_init_t: UDI drivers do not implicitly assume the use of locking, blocking, or any specific threading or synchronization model. They fit perfectly into any kind of host environment. As such, the UDI specification does not define any locking operations. It is completely possible for a host kernel to run UDI drivers locklessly. ~~<source lang="c">~~ ~~typedef const struct { // Don't forget that global variables are read-only~~ ~~udi_primary_init_t primary_init_info;~~ ~~udi_secondary_init_t secondary_init_list;~~ ~~udi_ops_init_t ops_init_list;~~ ~~udi_cb_init_t cb_init_list;~~ ~~udi_gcb_init_t gcb_init_list;~~ ~~udi_cb_select_t cb_select_list;~~ ~~} udi_init_info;~~ ~~</source>~~ ==Driver failures== When illegal behavior is detected by the environment, the misbehaving region will usually be region-killed and all neighouring regions will be notified. All channels to that regions will be closed and all resources owned by that region will be freed. ~~==Metalanguages==~~ ~~{{stub}}~~ ==See also== Line 165 ⟶ 154: * Combuster's effort on creating a [[User:Combuster/UDI_Graphics\|graphics metalanguage]] * Love4Boobies' page for several other [[User:Love4boobies\|UDI drafts]] ==Existing Implementations== * [http://projectudi.sf.net/ Reference implementation] - Mostly targeted at linux * [http://github.com/thepowersgang/acess2 Acess2] - Mostly complete implementation (with network support) * [http://www.d-rift.nl/combuster/mos3/ MOS3] ==External Links== Line 171 ⟶ 165: * [http://projectudi.sf.net/ Reference implementation] * [http://www.ties.org/deven/udi.html Deven Corzine's editorial] * [http://~~osr600doc~~uw714doc.~~sco~~xinuos.com/en/UDI_dwg/~~CONTENTS~~dwg_code_top.html UDI Driver Writer's Guide]