OSDev.wiki

Uniform Driver Interface: Difference between revisions

[unchecked revision][unchecked revision]
← Older editNewer edit →
Content deleted Content added
VisualWikitext
m Removed duplicate section
Replaced the unnecessarily technical "Initialization" section with a short note on the UDI programming model.
Line 138:
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.
 
==InitialProgramming stateModel==
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==
Retrieved from "https://osdev.wiki/wiki/Uniform_Driver_Interface"