OSDev.org

The point of UDI:

• a binary driver can be used by any UDI-implementing OS running on the same CPU;
• a source driver can be recompiled - without source changes - for any CPU that's running a UDI-implementing OS.

Actually, there are UDI-drivers and supporting platforms out there. However, Linux doesn't support it (because it's not "free" enough for their tastes), and Windows doesn't support it (because Microsoft has nothing to win, but all to lose if UDI made it to mainstream). Add to that that UDI is, as-of-now, limited to such "unspectacular" interfaces as disk drives, parallel and serial ports, it's easy to see how "supports UDI" isn't usually placed on the "features" list of, say, Solaris.

Look at SNAP. It provides a portable driver interface for graphics cards. How many people know about SNAP?

And then there's the chicken-and-egg problem: Is UDI bad just because it isn't mainstream? Reversing that logic would state that Windows and MSIE must be great products because everyone uses them...

Instead of people wasting thier time trying to make a global driver interface, they should just document the drivers and that way as many OSes as possible can port them.

Bull. Try porting an average Linux driver to a non-POSIX kernel and then tell me that is less work than writing a driver from scratch.

Not taking into account the recent discussion about certain types of drivers that will probably never be released as Open Source simply because they contain too much know-how about the HW internals. (nVidia / ATI)

Non-POSIX kernel? Try porting a Linux driver to a kernel that doesn't implement POSIX internally just the way Linux does.

UDI is large, corporate and hairy, but it damn well works.

-----8<-------------------8<----------------
I'm going to go out of my way to say this [rantish comment]:

The GNU people seem to think that they are the Open Source gods or something. They appear to have something against UDI because of it's backing idea. What's so bad about coperate usage of this system? Nothing I can see! If this plan went through, maybe I wouldn't have to **** with my Linux install every time I upgraded to get the darn sound working! Maybe then, Unreal Tournament 04 wouldn't run like crap on my linux! Ha! What if it was exploited for the good of the company? Who cares! Let them make money, it's not like they would be any poorer by not exploiting it! I opt to not include UDI, because it's just too unstable of a project to be seriously considered, espically with the GNU Gods ranting about legal issues surrounding the idea!

-------------8<-----------------8<-------------

Now for my response:

If UDI works for you, use it! POSIX to me is a waste of time in many respects, but then you have to worry about porting issues and the like. I probably will be shamed into partial POSIX compatability, but what they say is a little of a good thing is ok, but too much will make you sick... or something like that .

It dissapoints me that Nvidia doesn't even make a CLOSED SOURCE driver for linux (eg. one that is just dynamically loaded). I can see many happy gamers as a result. I mean, linux is more stable, secure, and looks nicer from the same distance (I'm trying to imply that they're (windows and linux) are both kind of off in many respects). If Nvidia does that, then a/the general version of it may be soon to follow .

While Solar _is_ right about porting, documenting the METHODS is what I believe is criticle to be able to share code in a "true open source way". rofl, like THAT'LL ever happen ;D.

Maybe we should all be trying to make our OSs load Window$ drivers or something. hahaha, then you only have to worry about window$-exclusive viruses and such. Not to mention any legal action M$ may take, :-X like a license model that prevents loading outside of a non-window$-native environment!

Dragon_Hilord wrote: It dissapoints me that Nvidia doesn't even make a CLOSED SOURCE driver for linux (eg. one that is just dynamically loaded). I can see many happy gamers as a result. I mean, linux is more stable, secure, and looks nicer from the same distance (I'm trying to imply that they're (windows and linux) are both kind of off in many respects). If Nvidia does that, then a/the general version of it may be soon to follow .

They used to. It worked somewhat. When it crashed (which it did quite a lot) you couldn't trace it or anything and the LKML people were like "you have a tainted kernel, we're not even going to try to figure out why it crashed inside our kernel". They might still have it though, but I doubt it'll be useful to you.

Maybe we should all be trying to make our OSs load Window$ drivers or something. hahaha, then you only have to worry about window$-exclusive viruses and such. Not to mention any legal action M$ may take, :-X like a license model that prevents loading outside of a non-window$-native environment!

Uhm... I'm not porting all their bugs and buggy drivers along with a load of good drivers. Rather be stuck without than with buggy drivers.

Why don't we develop our own driver standard for this community OS, which could then be understood and coded for each individual developer? After all, we don't really need a large standard like UDI since we're not going for world domination, we just need/want something that works well for our community project and preferably which we could port to our individual projects from without too much trouble.

If you want to come up with something so generic that it will be actually useful for the general public - i.e., microkernels, monolitic kernels, with or without POSIX in the back of their head yadda yadda, you'll end up with something just as complex as UDI I fear...

Solar wrote: If you want to come up with something so generic that it will be actually useful for the general public - i.e., microkernels, monolitic kernels, with or without POSIX in the back of their head yadda yadda, you'll end up with something just as complex as UDI I fear...

Making a device driver interface for all types of operating system now and in the future is comparable with the request to create a "something". No specifications given, but it has to run on my computer and I'll know if it isn't what I meant by "something". Good luck. Please do report back when you're done .

Doing just that for our business department all day. :-\

Solar wrote: Doing just that for our business department all day. :-\

That wasn't a silent hint at common business practice.

My point: specify something specific enough to do, or it won't suffice in any case. Basic reason for "requirements" to exist.

Users don't know what they want, but know when it's not working. And they spend much time trying to find strange combination of keys which will crush you application (or system) ;D

Alright, specifics: a sort of exokernel-functionality for device drivers, serving to do nothing more than abstract and protect the underlying hardware.

This leaves us with these things to abstract:
-DMA access (16 bit? 32 bit, definitely. 64 bit?)
-I/O ports (only for x86)
-Memory mapped registers (possibly abstract this similarly to I/O ports?)
-Hardware IRQs

A Mega-Tokyo compliant driver should be source-portable among Mega-Toky compliant kernels, but how applications talk to drivers (through the kernel, message passing, P-Call, data streams) shouldn't be standardized.

This model would also mean a (hopefully, needfully small) security model for device drivers. How the kernel performs driver security and maybe where the driver gets its privileges should be decided.

well, if you want to achieve something like "MT-compliant driver", that also means you have to provide an abstraction of all the features the driver could need: error logging, allocate virtual memory (for its own purpose or for buffers purpose), etc.

Pype.Clicker wrote: well, if you want to achieve something like "MT-compliant driver", that also means you have to provide an abstraction of all the features the driver could need: error logging, allocate virtual memory (for its own purpose or for buffers purpose), etc.

You're forgetting the idea that we can't even agree on the language - or the type of language - by far. You'd have to make one driver in OC/aml, Forth, C, C++, Assembly, Java, Pascal and probably a dozen others as well - at the same time! Don't forget that if they function suboptimal people will ignore it. So, stuff they don't use should follow a graceful fade pattern.

I think that such would be factors harder than just writing an OS with all drivers.