-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've done more thought, here's a small list of advantages on using
binary drivers, specifically considering UDI. You can consider a
different implementation for binary drivers as well, with most of the
same advantages.
- Smaller kernel tree
The kernel tree would no longer contain all of the drivers; they'd
slowly have to bleed into UDI until most were there
- Better focused development
The kernel's core would be the core. Driver code would be isolated,
so work on the kernel would affect the kernel only and not any
drivers. UDI is a standard interface that shouldn't be broken. This
means that work on the high-level drivers will not need to be sanity
checked a thousand times against the PCI Bus interface or the USB
host controler API or whatnot.
- Faster rebuilding for developers
The isolation between drivers and core would make rebuilding involve
the particular component (driver, core). A "broken driver" would
just require recoding and rebuilding the driver; a "broken kernel"
would require building pretty much a skeletal core
- UDI supplies SMP safety
The UDI page brags[1]:
"An advanced scheduling model. Multiple driver instances can be run
in parallel on multiple processors with no lock management performed
by the driver. Free paralllism and scalability!"
Drivers can be considered SMP safe, apparently. Inside the same
driver, however, I have my doubts; I can see a driver maintaining a
linked list that needs to be locked during insertions or deletions,
which needs lock managment for the driver. Still, no consideration
for anything outside the driver need be made, apparently.
- Vendor drivers and religious issues
Vendors can supply third party drivers until there are open source
alternatives, since they have this religious thing where they don't
want people to see their driver code, which is kind of annoying and
impedes progress
Disadvantages:
- Preemption
Is it still possible to implement a soft realtime kernel that
responds to interrupts quickly?
- Performance
UDI's developers claim that the performance overhead is negligible.
It's still added work, but it remains to be seen if it's significant
enough to degrade performance.
- Religious battles
People have this religious thing about binary drivers, which is kind
of annoying and impedes progress
- Constriction
This would of course create an abstraction layer that constricts the
driver developer's ability to do low level complex operations for any
portable binary driver
A Linux specific binary driver format might be more useful, but wouldn't
potentially allow for sharing the drivers across operating systems
[1] http://projectudi.sourceforge.net/about.php
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCMIK8hDd4aOud5P8RAo+EAJwIF7zEmiyxKzRJJ037TQ2FhYG5bACffTBX
JLhXPcidbQbf18LyTmjHgh0=
=gbyB
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
