-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
People are still e-mailing me about this?
Lennart Sorensen wrote:
> On Thu, Mar 10, 2005 at 12:24:15PM -0500, John Richard Moser wrote:
>
>>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
>
>
> Users would have to go hunting for drivers to add to their kernel to get
> hardware supported. Making a CD with a kernel and drivers for a wide
> variety of hardware would be a nightmare.
>
/pub/kernel/2.6
/pub/drivers/
>
>> - 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.
>
>
> But anything that runs in kernel memory space can still go trampling on
> memory in the kernel by accident and is very difficult to debug without
> the sources.
>
True, but that only should happen if you code things to access exact
memory locations, rather than asking the kernel for memory or mappings.
>
>> - 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
>
>
> That can already be done basicly. The makefiles work just fine for
> rebuilding only what has changed in general.
>
I don't remember what I was thinking
>
>> - 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
>
>
> I imagine a driver writer could still easily do something not SMP safe,
> but I don't know that for sure. It sounds like a very complex thing to
> promise a perfect solution for.
>
internally drivers would need to be smp safe, eh. Externally I guess
they're safe.
>
>>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
>
>
> Many of the disadvantages are a good reason why they have these opinions
> on binary drivers. They do impede getting work done if you have to use
> them on your system and something isn't working right.
>
>
>> - 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
>
>
> You forgot the very important:
> - Only works on architecture it was compiled for. So anyone not
> using i386 (and maybe later x86-64) is simply out of luck. What do
> nvidia users that want accelerated nvidia drivers for X DRI do
> right now if they have a powerpc or a sparc or an alpha? How about
> porting Linux to a new architecture. With binary drivers you now
> start out with no drivers on the new architecture except for the
> ones you have source for. Not very productive.
>
> [snip]
>
yeah, I was thinking the open source drivers would be ubiquitous to all
architectures anyway though. Closed drivers would be subject to lazy
venders.
> Len Sorensen
>
- --
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
iD8DBQFCML9fhDd4aOud5P8RAglXAJ9hTu5jVZcZ/LLFFw41bjO73+ShhwCfUlma
iPcrJXwKP0ZfQ8jCsVhxhSQ=
=CknT
-----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/
