More UDI [Split From: Alt-OS devroom at FOSDEM]

[gravaera]

Hmmm...they're working on a platform independent driver API, huh? I wonder where I've heard that before? Oh, right:

http://www.ties.org/deven/udi.html
http://udi.certek.com/

[Kevin]

You know I'm asking this each time it's brought up, and I'm going to continue asking until I get a answer: Where are the hobby OSes using UDI, so that one could have a look at what an implementation would look like? From the links in the wiki I get the impression that it's some abstraction levels too high for me to be productive.

[gravaera]

You know I'm asking this each time it's brought up, and I'm going to continue asking until I get a answer: Where are the hobby OSes using UDI, so that one could have a look at what an implementation would look like? From the links in the wiki I get the impression that it's some abstraction levels too high for me to be productive.

Hi, Kevin,

This question can be broken, by analysis into two logical questions, with the second one being dependent on the 1st:

"Where are the Hobby OSs that are large enough to be in need of mass hardware support" and "Of those, where are the ones that have looked to UDI?"

I think maybe the most critical problem with asking a question like this is that there are no hobby OSs that have become mainstream enough to need large numbers of drivers.

The second point is that of those OSs that are gaining in acceptance, like Haiku and the rest, the majority are turning to trying to port BSD and Linux drivers without any thought to the next set of upcoming OSs. Linux and BSD drivers aren't particularly considerable where portability is concerned.

And the new OSs, when they gather strength, alsways go and repeat the same error, by just porting with only consideration of how to make drivers best work on their own kernel.

I believe by now you get that I'm trying to say: "The problem isn't difficulty, but laziness." It's easier to change only parts of a ported driver to suit your specific needs, than to have each driver restructured to fit a specification before porting.

But by that same line of thought, unless that attitude is stamped out of the 'Alternative' OS community, this effort by these folks will receive the same treatment.

Unless of course this new effort receives support from small persons who contribute drivers continually, until they have a large base. But that wouldn't make it any better than UDI, or prove that UDI was inferior: it would just mean that this new idea had the drivers needed to make the masses realize that having a standard interface is useful to them.

Note weel that I have no partiality for UDI: It is simply contemporarily the best driver interface specificatio out there, and it would be best if people stopped reinventing the wheel and got to supporting it.

If this new proposal turns out to be better than UDI, then being the better solution, it would of course, follow, that for the benefit of all, it should be supported.

--There's your answer,
gravaera

[Kevin]

This question can be broken, by analysis into two logical questions, with the second one being dependent on the 1st:

"Where are the Hobby OSs that are large enough to be in need of mass hardware support"

I don't think I implied this question. Actually, I even think this question is completely wrong. Need for drivers doesn't imply being large. Even if it's just my small OS which I intend to keep private, I still needs drivers for the network cards of my test computers. Every OS that can do more than printing Hello World needs drivers.

and "Of those, where are the ones that have looked to UDI?"

I think maybe the most critical problem with asking a question like this is that there are no hobby OSs that have become mainstream enough to need large numbers of drivers.

So you're stating that UDI isn't implemented in hobby OSes because noone needs it, right? That sounds quite discouraging. Then why the whole UDI hype? As stated above, I think for the need for drivers it's completely irrelevant if an OS is mainstream or not - in practice, not being mainstream means that they are not available despite the need.

Unless of course this new effort receives support from small persons who contribute drivers continually, until they have a large base. But that wouldn't make it any better than UDI, or prove that UDI was inferior: it would just mean that this new idea had the drivers needed to make the masses realize that having a standard interface is useful to them.

Note weel that I have no partiality for UDI: It is simply contemporarily the best driver interface specificatio out there, and it would be best if people stopped reinventing the wheel and got to supporting it.

I'm not sure if I should call it partiality. But at least you seem to support something that doesn't exist in reality. All I'm asking for is an example of what it looks like in practice. And the answer is always the same: There is no working implementation in practice. I can't see what would support the claim of being the best interface under these circumstances. You don't even try to explain what makes it good (perferably by code). I made the point that I think it's too much abstraction, you didn't even try giving an answer to that.

You're merely arguing for a standard interface, and on that topic my opinion is the same, so no need to discuss it.

If this new proposal turns out to be better than UDI, then being the better solution, it would of course, follow, that for the benefit of all, it should be supported.

What do you think makes a proposal better than UDI? Or even, how could one make a sensible comparison as long as no UDI implementations in the hobby OSes of this community exist, so nobody knows what it looks like in practice?

--There's your answer

Unfortuately, the answer was "I don't have an answer", so I don't think that counts.

[Combuster]

This question can be broken, by analysis into two logical questions, with the second one being dependent on the 1st:

"Where are the Hobby OSs that are large enough to be in need of mass hardware support"

I don't think I implied this question. Actually, I even think this question is completely wrong. Need for drivers doesn't imply being large. Even if it's just my small OS which I intend to keep private, I still needs drivers for the network cards of my test computers. Every OS that can do more than printing Hello World needs drivers.

And you can get away with 10 lines of keyboard code, and a lists of VGA register values to do the next 101 things on your todo list. You need an established codebase to start considering running hardware specific drivers.

Unless of course this new effort receives support from small persons who contribute drivers continually, until they have a large base. But that wouldn't make it any better than UDI, or prove that UDI was inferior: it would just mean that this new idea had the drivers needed to make the masses realize that having a standard interface is useful to them.

Note weel that I have no partiality for UDI: It is simply contemporarily the best driver interface specificatio out there, and it would be best if people stopped reinventing the wheel and got to supporting it.

I'm not sure if I should call it partiality. But at least you seem to support something that doesn't exist in reality. All I'm asking for is an example of what it looks like in practice. And the answer is always the same: There is no working implementation in practice. I can't see what would support the claim of being the best interface under these circumstances. You don't even try to explain what makes it good (perferably by code). I made the point that I think it's too much abstraction, you didn't even try giving an answer to that.

UDI exists alright. There are implementations for mainstream OSes, there are drivers. The problem is, mainstream OSes think their (...) is larger. People like you want to copy paste code that just works, which is generally a bad idea and given the huge variations in host OS designs, it will not work. People refuse to see what UDI can do for you, and reject it based on the lack of support. Even if you design something better than UDI, you still have the problem that there is no established code base. By blaming UDI, you are blaming yourself for not spending time on it.

You're merely arguing for a standard interface, and on that topic my opinion is the same, so no need to discuss it.

Well, it doesn't show.

Now for your original question, I am working on an UDI implementation. Because I can. And because of people who like to bully something because they can get away with it. You are not helping.

</rant>

[gravaera]

Hi again, Kevin:

I'll have to say that due to UDI's lack of 'plain to see' implementation support, I guess you win, but a note to make before I drop the sub-debate:

UDI is actually very light, and there is hardly any real set of abstraction layers on top of the host OS. The most you would have to do is create a layer on top of your Driver Mgr which allows for some type of queueing of requests since UDI almost implies a request queue system.

But by all means please do read the specification yourself. You actually have a community, stable OS going. It would be great if you could give the momentum needed.

And I re-read my original message just now, and it seems to convey the message that I disagree with the whole convention, or whatever the event of the topic is.

To clear things up in case my post came across that way to anyone, I like the idea that BSD is getting interested in hobby projects. I only find it strange that they're going to try to make a whole new API for driver portability when there's no need.

What do you think makes a proposal better than UDI? Or even, how could one make a sensible comparison as long as no UDI implementations in the hobby OSes of this community exist, so nobody knows what it looks like in practice?

I found that to be a very practical question. I'll stew over it for a while and reply again later.

--All the best,
gravaera

[Kevin]

And you can get away with 10 lines of keyboard code, and a lists of VGA register values to do the next 101 things on your todo list. You need an established codebase to start considering running hardware specific drivers.

Right, obviously I was exaggerating. My point is that there's still a lot of non-mainstream hobby OSes fulfilling this requirement.

People like you want to copy paste code that just works, which is generally a bad idea and given the huge variations in host OS designs, it will not work.

Wait, why does it work in UDI then?

Or are you not referring to drivers but the implementation? If so, no, currently I have no plans of implementing UDI - and if I did, I'd probably try to implement it in terms of CDI which I guess your code doesn't do. I'd just like to see what a typical implementation looks like.

Even if you design something better than UDI, you still have the problem that there is no established code base. By blaming UDI, you are blaming yourself for not spending time on it.

I'm under the impression that in practice CDI is more established among hobby OSes than UDI is, and it already gave me some additional drivers. And this in a stage where we feel ourselves that it's not complete enough, so we didn't even try to announce it loudly - whereas you UDI guys chime in in every discussion potentially related to driver interfaces and still in fact nothing happens.

Now for your original question, I am working on an UDI implementation. Because I can. And because of people who like to bully something because they can get away with it. You are not helping.
</rant>

Cool, do you have any source code online, maybe some git repo? (ignoring the rant)

[Kevin]

What do you think makes a proposal better than UDI? Or even, how could one make a sensible comparison as long as no UDI implementations in the hobby OSes of this community exist, so nobody knows what it looks like in practice?

I found that to be a very practical question. I'll stew over it for a while and reply again later.

All my questions were meant to be very practical.

I think in the past discussions we've discussed more than enough about theoretical benefits. But in the end theory doesn't help me with connecting my computer to the network.

But by all means please do read the specification yourself. You actually have a community, stable OS going. It would be great if you could give the momentum needed.

I did look at the driver write's guide or what it's called a few days ago. I'm just wondering when we're going to start programming on the meta-meta-meta level.

[fronty]

I thought there was some sort of UDI reference implementation.

[Combuster]

There is
Just our dear friend Kevin wanted to see a hobby OS implementation

[fronty]

I thought his main point was to see how the implementation could look like.

[Combuster]

If that'd be true, he thorougly broke forum rules by not searching, at least twice.

[Kevin]

The point why I was asking for a hobby OS implementation is that the reference implementation is probably very extensive. So if I'd say "this looks like a whole lot of stuff to implement!" you'd probably say "no, in fact you don't need all of it". Hobby OSes in contrast tend to keep things simple. The same goes for the driver side: There is this shrkudi driver, but it looks relatively complex (at least over 5000 LOC look like much code. I can't really compare it because I don't know the what the hardware looks like and what features are supported by the driver). I'd rather see the typical small ne2k/rtl8139 implementation of a hobby OS.

Edit: By the way, you seem to have missed my question if there is any public repo of your source. I would really be interested in it.

[Love4Boobies]

Hey, UDI again

I didn't actually read the whole thread since I'm away and don't have much time for the Internets. However, there are hobby OSes that implemented UDI and I'm surprised no one knows about them - one example that comes to mind is O3ONE. The reference implementation contains UDI environments for several OSes including FreeBSD, Linux 2.4 (never tested it under 2.6), Darwin, Mach, Solaris and I can't remember what else. Do not download the release from the SourceForge page since that's a couple of years out of date; look under the udiref branch using CVS.

As for drivers; there are quite a lot of them. You'll have to look on SCO's FTP server. Unfortunately that's a mess and you'll find drivers everywhere - they're not the same under all OSes, they're not all in the "drivers" directories, sometimes they're under directories you wouldn't think to look in and... even worse, they're sort of mixed with DDI drivers so you'll have to take your time.

[Kevin]

However, there are hobby OSes that implemented UDI and I'm surprised no one knows about them - one example that comes to mind is O3ONE.

Thanks. Unfortunately he writes a lot about UDI, but I couldn't find it included in the sources that can be downloaded.