Should I get on the UDI train?

[JackScott]

Anyone got any suggestions for a domain name we should use?

Do not lose sight of the real goal. Drivers are the key, everything else is secondary.

[Owen]

Anyone got any suggestions for a domain name we should use?

Do not lose sight of the real goal. Drivers are the key, everything else is secondary.

True, but having a common repository for those drivers would be useful. More important, however, is having a common place to store and discuss the bindings that are developed - at present, there aren't many, and if we fail to discuss them we will end up with multiple, or one accidentally engineered for a specific kind of hardware.

[blobmiester]

There is a simple way around the copyright issue, as I said: If we need to modify the specification in any way going forward, then we just rewrite it but maintain the interface that exists. Yes, it will be tricky and time consuming, but it is doable.

Then let's do this now. I'm all for going forward with massive driver development in UDI but I'd feel a lot more comfortable if we get off to a good, clean start -- with zero copyright issues.

And for a web domain -- we should rename UDI first to ... something. Just to make it appear new.

[gravaera]

Hi:

Listen: "Let's rename!" and "Let's fork!" and all that crap should stop. UDI is an extensible specification. Wherever you need to venture out into strange waters where the core specifications and accepted current metalanguages do not suffice, you design a new metalanguage and submit it for review. If it's accepted, you move on, and it is standardized. If not, you just make that metalanguage your own proprietary thing. When the UDI board or whatever has officially backed a particular API (metalanguage), then the general UDI community will back that.

We DO NOT need to have a "new" specification. So all of this overzealousness can wait. And should anyone want to go about refuting that, then why don't we set out these logical points?:

* A person who does not have a UDI environment does not know about the particular stresses involved in implementing UDI.
* Therefore said person does not know enough about the extrapolated general case to decide what to do for the general UDI community.
* As a result, a person without a UDI environment should refrain from getting excited and trying to move the core spec in any bizarre direction.

Calm down. Leave it alone until there's someone who implements it, and determines that there are difficulties involved. To my knowledge, the only two people on this board who have anything close to an UDI environment are Combuster and ThePowersGang. ThePowersGang has not posted here, and Combuster rebuffed the idea of a fork. Let's be patient, yea?

--Remain calm
gravaera

[thepowersgang]

May I just quickly say thank-you for reminding me about my UDI interface, I was looking for something new to work on

The UDI spec is a little confusing, mostly because (like the C spec) there is a lot in it that is not actually needed to run the most basic drivers, however it is also very extensible and theoretically works on any system that implements UDI.

[Solar]

Infrastructure set up at http://udi.rootdirectory.de.

I know both the domain name and the SVN repository URL ( https://srv7.svn-repos.de/dev34/udi/) are not "sexy", but they're set up and for free. We can move to a "better" domain name once we have anything to show for it. Until then, I'd suggest we focus on content.

If you want an account for the site and the repo, drop me a PM.

As for mailing lists, why not just use those of Project UDI? Or are they defunct? http://udi.certek.com/f-reflector.html

[Kevin]

The Common Driver Interface (CDI) was created on a German OSDev board that I've now forgotten the name of. I'm pretty sure the Pedigree project, amongst others, has a working implementation.

Yes, Pedigree does have some support for it as well as a couple of OSes that originate in the German-speaking OS dev world.

CDI is a more straightforward approach and aims at being easy to implement for new OSes. I feel that UDI in comparison has got the abstraction one or two level too high. (And effectively, basically noone in this community actually has a working implementation of UDI - it's all just intentions.)

However, unlike UDI (IIUC), CDI does not provide binary compatibility, it's all about compatibility on the source level. It's probably not as mature as CDI, but it can (and will) be changed as the community feels it should. And unlike UDI, it has proven useful for a couple of hobby OSes already.

The repository is at http://git.tyndur.org/?p=cdi.git;a=tree and discussions in English take usually place in #tyndur on irc.euirc.net.

[Solar]

CDI is a more straightforward approach and aims at being easy to implement for new OSes. I feel that UDI in comparison has got the abstraction one or two level too high.

Well, it's a matter of what's your goal, isn't it? To quote Gollhardt:

The UDI APIs were very carefully designed to work in a wide variety of O/S architectures: real-time, time-sharing, or virtual; server, desktop, or embedded; traditional kernels, micro-kernels, or distributed systems; single processors or highly parallel systems with or without shared memory; drivers running in kernel space, user space, on dedicated I/O processors, or over a network. All of these possibilities and more without ANY change to the driver code.

Many factors lead to this flexibility, including an asynchronous message-based API (even for resource allocation); a precisely-defined model for memory usage; O/S-driven driver instantiation, discovery, and I/O resource assignment; and, in general, hiding as much detail as possible from the driver about the O/S implementation and the underlying hardware platform. Have we covered every possible architecture? Probably not, but we've come a whole lot closer to it than any other driver API I've seen.

Of course, if you cut away some of the flexibility, you can make a simpler interface...

[Kevin]

Right, there is rarely a one-size-fits-all solution. Which is why I don't quite understand why people seem to advocate UDI as the one and only solution (and of course don't implement it anyway).

I for one think that most hobby OSes don't need half of that flexibility. If they could exchange it for some more simplicity I think it would be a win for them. And in fact, as long as you don't aim for binary compatibility, flexibility isn't hurt all that much with simpler approaches.

[Creature]

I think the amount of hobby OS' we have here is somewhat comparable to the amount of linux distro's around (there are loads and they will keep increasing). Linux drivers usually require building from source when you want to run them on some extravagant linux distribution, though the source may not always be freely available (read e.g.: Nvidia?). That's where I see a potential benefit of having binary compatibility. All the hobby OS has to do is make sure it has a working UDI implementation and it can run any graphics/network/miscellaneous driver written using UDI from OSDev (whether closed-source or open-source, taken everything regarding copyright is in order of course). So rather than having to wait for someone else to release the source, give you information or even having to make bugfixes because the source won't immediately compile for your OS, all you need is your UDI implementation (which you can write yourself) and you're practically done.

Of course, having lots of UDI drivers may keep people from writing their own drivers, but I guess if you really wanted to write a driver, you can always try to improve upon the existing, write your own better driver, or just write one for learning purposes.

[Kevin]

If closed-source drivers are a feature or a bug is a discussion I really don't want to get in...

But honestly, is it even relevant? Do you expect Nvidia to write a (binary) driver for any of our hobby OSes? The scenario I'm thinking of, and which I believe is the only realistic one, is that we as a community want to share drivers between our OSes.

[Creature]

I wasn't pointing at the fact Nvidia may write drivers for UDI, I was pointing to the fact that we ourselves could someday, after several lives (wiki: "If you have more than one life to waste"), have a couple of graphics drivers we could exchange between our hobby OS', without the need to build them for each and every one of our OS, but rather that they'd work without problems, which is because we'd be using UDI.

[Kevin]

I'm not sure where the connection between "building the driver yourself" and "not working wihout problems" is. If building the driver is a problem, there's something wrong already. A binary driver wouldn't be a solution but merely a workaround for that.

[Owen]

Right, there is rarely a one-size-fits-all solution. Which is why I don't quite understand why people seem to advocate UDI as the one and only solution (and of course don't implement it anyway).

I for one think that most hobby OSes don't need half of that flexibility. If they could exchange it for some more simplicity I think it would be a win for them. And in fact, as long as you don't aim for binary compatibility, flexibility isn't hurt all that much with simpler approaches.

UDI is as close to a one size fits all approach as possible. Seriously, have you read the specifications? Yes, they're long - but they're not all that complex. It
is really well designed. It scales. It was designed by people who had years of OS development experience, from companies which have used a variety of kernel designs.

The Common Driver Interface (CDI) was created on a German OSDev board that I've now forgotten the name of. I'm pretty sure the Pedigree project, amongst others, has a working implementation.

Yes, Pedigree does have some support for it as well as a couple of OSes that originate in the German-speaking OS dev world.

CDI is a more straightforward approach and aims at being easy to implement for new OSes. I feel that UDI in comparison has got the abstraction one or two level too high. (And effectively, basically noone in this community actually has a working implementation of UDI - it's all just intentions.)

However, unlike UDI (IIUC), CDI does not provide binary compatibility, it's all about compatibility on the source level. It's probably not as mature as CDI, but it can (and will) be changed as the community feels it should. And unlike UDI, it has proven useful for a couple of hobby OSes already.

The repository is at http://git.tyndur.org/?p=cdi.git;a=tree and discussions in English take usually place in #tyndur on irc.euirc.net.

There are some problems I see with the CDI specification:

• Lots of it only written in german
• No concurrency within a driver possible
• Driver cannot provide multiple interfaces
• Incorporates portions of the C standard library - then expects them to be used in nonstandard ways (e.g. why does the FS driver contain a FILE*?!)
• Synchronous model (or at least seemingly so). This is a big issue when you have a single-threaded interface model (UDI also has a single threaded model - but is asynchronous, and allows dividing a driver into units)
• No defined interface for drivers to call other drivers. This one is incredibly useful and important.

OK, its somewhat more complex, but the complexity is useful.

And I know at least one OS developer here (Creature?) has said that he was switching away from CDI because it was too simple. I believe he was heading to UDI?

[XanClic]

Lots of it only written in german

True, but as far as I can see, the Pedigree people can use it anyway (besides this is not a “technical” problem).

No concurrency within a driver possible

True. The CDI library of the OS has to make sure that there's only one instance of the driver running (afaik). Well, I could say that this makes driver development somewhat easier.

Driver cannot provide multiple interfaces

What do you mean with “interface”? If you mean the CDI driver structure, this shouldn't be a problem by design. One driver could register itself both as a network and as a storage driver. I don't know if all CDI implementations would handle that correctly, but the CDI design doesn't forbid that (afaik).

ncorporates portions of the C standard library - then expects them to be used in nonstandard ways (e.g. why does the FS driver contain a FILE*?!)

That's not a bug, it's a feature.
Why should you define special functions if the stdclib has them already, like e.g. malloc or printf? Thus we made the decision that parts of the that library are free for use to drivers, though it's yet to be standardized, which functions are allowed. As for me, using a FILE pointer is not a thing I'd do, too.

Synchronous model (or at least seemingly so). This is a big issue when you have a single-threaded interface model (UDI also has a single threaded model - but is asynchronous, and allows dividing a driver into units)

I'd discuss that if I understood… Well, a point for CDI, I'm not too stupid to understand it.

No defined interface for drivers to call other drivers. This one is incredibly useful and important.

We're already discussing that one (because it is a requirement for a future audio layer and might be for CDI.usb).