A Sun engineer on Linux

Posted Sep 23, 2004 22:58 UTC (Thu) by mmarq (guest, #2332) [Link]

" be transferred from disc (via DMA) straight to network card buffer - without processor help and in some cases even without main RAM involved...
... drivers know enough about kernel internals to easily shuffle data around in such a way. It's very hard to develop something like this with "split drivers". "

Processores, memory and disk always had plenty of good support in many Open Source kernels, *you simple dont have to put everything under a 'split model'*.

By the way, it is very hard to me to discuss deep technical details of kernels, but never the less i suspect that with my example about D-BUS extension it wouldn't be that hard,...
...hmm... lets see, it makes no sense to have a 'split' driver extension to Integrated Device Electronics disks so well integrated will all kernels, i belive!... but it makes every sense to have them to support the different "southbridges" that implement so many different ATA( and some SCSI) controllers with different RAID capabilitys.
"We" already have in linux a 'block devices' subsystem(dont know if i can call it like that) that supports RAID and other features in modules, "we" have a SCSI subsystem with lot of features in modules,... "we" could have an ATA subsystem of the same sort, or a unified disk subsytem,..., with features in modules and all soon implemented by Kobjects,..., making those kobjects speak D-BUS+(example) and load other small *extension* modules that support the different southbridges, not present in any of the kernels modules anyway, dont seem to me to be that HARD(not wishfull thinking i hope)...

" Proprietary drivers have nasty tendency to become broken and obsolete long before hardware becomes unusable... "

That is the main reason because a split model, not ABI compliant, makes all the sense... nasty or not the software can be mended, but the hardware can only be changed, even inside a family... as simple as that.
So there is a "small" part of the driver that in my view, and evebodys else also, i belive, can easly be connected to a particular piece of hardware, and stays connected to that particular piece of hardware until the end of the live cycle of both, no mater if they were and still are loaded by a common "MAIN" driver... like in the NVIDEA example that loads from a single "driver", support from the ultraobsolet TNT to the ultramodern 6000 family.

"You can be very sure binary drivers for "split driver model" will have a lot of kludges,... "

True. But worst than kludges is no support at all... and you can always harden the kernel, like in patches that circulated before 2.6.0, i belive, and that were supposed to kick out from running any kernel module that breaks... and join to that the possibility of load the tiny 'split' extension portion, in RING 0 or RING 1 of the processor, far way from userland where Windows drivers get massacreded by all sort of "your computer is mine" software and other malware.

And if a 'split model', light on overhead, and with little "intrusivity" because it dosent need an ABI compliance, is negociated trough out the all Open Source landscape, i belive, the hardware industry will jump right on because the "same" driver will be possible to run from OpenDarwin(Apple Iron) to the BSDs to Linux and OpenSolaris... then we get to know which kernel is the best, and not having people talk the talk in blogs, and them having excuses for not being able to walk the walk.