> It's not that drivers are fundamentally hard. It's that the hardware > we work with is undocumented crap. Linux drivers know all the secrets; > we're riding on that knowledge.
And so do millions more, perfectly understandably. The problem is that "all the world is Linux" is not a good mantra. Porting drivers from Linux to, say, NetBSD is a nightmare, multiplied by the number of useful target OSes. Whereas XEN largely suffers (only) from inefficiencies accessing the lower layer, whenever it (and you, if I understand your recent discussions) tries to punch through the barrier, the mysteries strike again. (In passing, I was looking at ISDN adapter drivers with a view to implementing the functionality under NetBSD. The Linux driver, in my opinion, was orders of magnitude better coded than the FreeBSD version. Take that any way you like, it has changed my opinions on Open Source device driver developers.) To return to the main issue, I think effort applied towards documenting "undocumented crap" would have a wider scope than adopting or reverse engineering the knowledge in Linux drivers code. The latter is certainly a more immediate objective. Of course, one then also needs to deal with binary-only drivers and other such stumbling blocks, but my hope would be that eventually hardware manufacturers will get the message or will get deselected :-) Given the choice between using Linux kernel source as the documentation, versus Plan 9 kernel source, there are too many good reasons to pick the Plan 9 option to list them here, where they are in any case taken for granted. Hence my preference for a 9load-type BIOS on which others besides Plan 9 can build. (The philosophy, probably flawed, is that Open Source principles are "right" in some transcendent way and that a "good" manufacturer cannot continue to overlook the benefits of being on the "right" side of the line. Communism had the same underlying principle and landed up on the scrap-heap of history.) ++L
