OSDev.org

The main obstacles to this are twofold:

1.Proprietary hardware - Not everything has released and known specs. Bastards.
2.The existing open source code is horribly documented - What this really means is that us OSdevers are too lazy to put the effort into reading some guy's monstrous driver, for a device we don't personally own, in the Linux kernel.

Crazed123 wrote: What this really means is that us OSdevers are too lazy to put the effort into reading some guy's monstrous driver, for a device we don't personally own, in the Linux kernel.

Or maybe it means that the developers who write Linux drivers are too lazy to properly design and document their code.

[me=Colonel Kernel]ducks in case any Linux people visit this forum... [/me]

Or maybe the developers who write drivers for Linux are more concerned with making their drivers work for people filling their inboxes with problem reports, than trying to help other people write drivers for totally unrelated, should we even say irrelevant operating systems.

I've been working with linux drivers lately, and still fighting with a linux module atm. Let me tell you one think: Linux kernel is a jungle. It's moving all the time ... it's alive.

version 2.6.9 uses "qdisc->qtats" where version 2.4.xx used "qdisc->stats" and (of course) both substructure aren't identical (though some names match between the two). Guess what you should use on 2.6.5 ? ... right! the same as the one in 2.4.xx !

I can tell you similar stories about macros for accessing page tables, and the like.

<quit ranting, go eating>

Crazed123 wrote: The main obstacles to this are twofold:

1.Proprietary hardware - Not everything has released and known specs. Bastards.
2.The existing open source code is horribly documented - What this really means is that us OSdevers are too lazy to put the effort into reading some guy's monstrous driver, for a device we don't personally own, in the Linux kernel.

Well I was talking along the lines of trying to document the existing ones by looking at them, we could probably get a few good ones out of that.

SkyOS for example has reversed their own Radeon driver, I don't know if they're under NDA (or just out of being closed wouldn't want to) help with atleast getting us off the ground with understanding if we asked.

Colonel Kernel wrote:

Crazed123 wrote: What this really means is that us OSdevers are too lazy to put the effort into reading some guy's monstrous driver, for a device we don't personally own, in the Linux kernel.

Or maybe it means that the developers who write Linux drivers are too lazy to properly design and document their code.

[me=Colonel Kernel]ducks in case any Linux people visit this forum... [/me]

The difference is a matter of opinion, but basically yes. The Linux kernel is a nasty jungle with Viet-Cong and malaria-carrying mosquitos in it.

mystran wrote: Or maybe the developers who write drivers for Linux are more concerned with making their drivers work for people filling their inboxes with problem reports, than trying to help other people write drivers for totally unrelated, should we even say irrelevant operating systems.

The best thing any developer can do for themselves is to carefully design and fully comment their code. If the code isn't maintainable, then it is destined to become an insufferable mess. From a business point of view, it becomes far too expensive to deal with those problem reports.

If good documentation also helps us hobbyists, so be it... but that is certainly the least of the reasons why good development practices should be used. This is what defines the difference between hacking and software engineering.

True, but what I read on OSNews/Slashdot/etc. when this topic comes up always makes me think that the *real* reason the Linux kernel developers don't standardize a driver interface or document is to keep the kernel and drivers Free Software. For all the open-source-practicality stuff I've heard from Linus himself, most Linux kernel and driver developers seem to fear proprietary-licensed drivers. Bah.

[me=Crazed123]goes to read RMS's work on that topic again.[/me]

Crazed123 wrote: most Linux kernel and driver developers seem to fear proprietary-licensed drivers. Bah.

Can't blame them for that. There's an impressive amount of people that will come to the mailing list saying "there's a bug here" after they loaded a proprietary driver, leaving the kernel developer clueless on what might have gone wrong (they couldn't tell since there are blackboxes in the system).

Dex wrote: PS: This link is a typical example of a useless talking shop ( or in this case doc) Project UDI.
Doc like this, come about from people, who do not like coding, but love to type, if the same effort was put into writing drivers, with all OS dependant code in a separate file, that would be more usefull.

HP, Intel, Sun, Unisys, IBM, Adaptec, Compaq, Lockheed... that's the real world out there, and in that world people don't just push several dozen well-payed engineers into a room and tell them "write code!". They first decide on what they want, then they write up the whitepapers, then they estimate how much it will cost, then they estimate if it will be worth it, and then they get the engineers started.

Oh, and BTW... the reference implementation is over at SourceForge, working for FreeBSD, Solaris, UnixWare, Linux, and Darwin, with drivers being available for IDE, network and USB devices.

Your criticism, thus, is pointless.

Dex wrote: Its very easy to get round this problem, you take a cheap, common device for things like sound, graphics etc, with well documented driver interfaces and you write drivers for it, as per your OS design.

I agree 100% ,but there is a small problem: hardware changes very fast, i hava a SB pro driver on my OS but now this card
is obsolete and you can?t buy it.Also we are 0.001% of the
computer market and pc makers don?t care about us.But i like
your idea.

The AC'97 sound card, on the other side, is well defined, well documented, massively implemented and not obsolete afaik.

It'd be interresting to rewrite those drivers (i mean, RTL8139, AC'97, ATA, ATAPI, etc.) in Os-agnostic fashion so that you can write your own driver for your own OS by just writing glu code between an "AC'97 library" and your own OS's needs.

Crazed123 wrote:...a UDI environment must sandbox drivers in the rough equivalent of a small separate operating system. For that much effort you might as well just fully virtualize the driver to fool it into thinking it's running on bare hardware.

Pype.Clicker wrote: It'd be interresting to rewrite those drivers (i mean, RTL8139, AC'97, ATA, ATAPI, etc.) in Os-agnostic fashion so that you can write your own driver for your own OS by just writing glu code between an "AC'97 library" and your own OS's needs.

Which means you put lots of abstracting / virtualization effort into an OS-agnostic AC'97 library - one driver, although I'll admit a very useful one - instead of adding the UDI abstracting / virtualization layer to your OS...

I know UDI isn't perfect (wouldn't work for 3D gfx and would require additional work to work for sound), and I understand look-at-the-size-of-that-thing part of it (probably oversized for a casual hobbyist project).

On the other hand I see the awesome potential of it - driver binaries portable as long as the CPU stays the same, driver sources portable among all UDI systems... even the HW manufacturers would love it if it only would get more attention / installed user base...

Then again, between Microsoft shying it like the devil shies holy water and GNU considering it evil incarnate...

I would personally argue that by trying to get one or two drivers work with a few kernels using some kind of semi-designed interface, it would be much easier to figure out what exactly such framework needs.

Most frameworks (driver frameworks just as one example) have the problem that 99% of the functionality is totally unnecessary 99% of the time, and it would be cheaper (in terms of time invested) to just special case the remaining 1%.

As for binary drivers being portable, all you need is a common, relocatable, binary format and a finite interface. So if you can have a clean API (and ABI ofcourse) that never has to be bypassed, then coming up with a suitable binary format is just a matter of choosing one.

Isn't the whole point of the UDI project that they have done just that?