OSDev.org

It's doesn't have a reference implementation because nobody has implemented one yet.
And it appears dead because nobody has implemented it yet.

Well, if there were a driver for something like a floppy drive or anything already made, then that alone would make it worth implementing(since it looks easy to implement anyway) but I'm afraid I will gain nothing by having it in my kernel.

In the German community Lowlevel we have come up with a similar idea (shared drivers between different OSes) and agreed on a standard called CDI (Common Driver Interface). As opposed to the sophisticated design of EDI, I think CDI is a a fairly trivial and straightforward thing. Maybe this will be a limiting factor in the future, but it worked out quite well for now and there actually are some drivers.

Unfortunately for you, CDI is a project of a German community, so most documentation is only available in German. Anyway, here a few pointers:

• CDI-Directory of tyndur source (identifiers English, comments German)
• CDI in the Lowlevel wiki (German)
• CDI in the meinOS wiki (English)
• Doxygen documentation (German)

In case there is any interest, we might find some folks in our community who volunteer to translate more of it.

Don't forget about the UDI (Uniform Driver Interface). It's probably the most complex and is probably more common; although unfortunately, there is really no such thing as a common driver interface. You can really gain any benefit from implementing any of these in your kernel.

UDI is not really accepted (by GNU esp.) due to philosophical concerns - people are allowed to make non-open-source UDI drivers and that's not good for open-source-ness apparently. That's why they didn't want UDI in Linux.

I find that ridiculous.. there are many kernel module driver blobs out there.. why don't they keep linux from supporting kernel modules too then?

Not sure if UDI is the right thing for the goal of most peopl here, but good to have the link in this thread. The main question is if you want to have a complete framework or rather something simple. UDI definitely doesn't look like something for implementing on a saturday afternoon.

I thought UDI was dead... Anyway, the GNU folks really have nothing at all to do with the linux kernel. They may not have wanted UDI in the kernel, but that's not the reason it isn't in the kernel. The real reason UDI isn't in the linux kernel is because the linux kernel devs don't believe in having a stable driver API. They find it too limiting. Just look at linux-2.6.29/Documentation/stable-api-nonsense.txt for more information on that.

I didn't mean they did



I wasn't aware of that. I just remembered reading what I said on the wiki. I'll be sure to check that file.

Hi, Ive had a simple idea for portable drivers for a little while, maybe this is the best place to discuss it.

The main goals of a portable driver is so the device works in any environment with some small supporting functions. The driver doesnt need to be the fastest or best, just stable and offer the most common and necessary functions.

With this in mind the interface i imagine is similar to a BIOS type interface in a relocatable binary (or maybe elf) format. This file can be loaded at driver initialisiation or compiled into a kernel or driver.

The OS needs to wrap a small support driver around the binary so the functions are native to the OS but then 1 function entry call into the binary file with a service no and some parameters would do all the work. A simple driver library (inside the wrapper driver) would also work this way with 1 function entry call using a service no to access OS services like, call BIOS interrupt, allocmem etc...

quick vga example

driver.c



vgadrv.c


The header in the driver file has areas to assign entry points for thiese functions or other memory areas that a specific device might need. The header hasnt been designed, ive only just thought about a simple way to give a device's function's an easy way to be accessed.

the ioctl interface can be extended easier with more functions or removing functions as each function doesnt need to be linked.
The BIOS used this method for years, and in a way, this is how a normal syscall works. Pass a service no and its parameters thru 1 entry point.

I don't think that this is necessarily a good Idea. With this approach you'll have to do much more work to check data types and parameter count. If you use a wide interface, the compiler does this work for you provided that you use a static typed language. Of course it is simpler to change your type of interface, but you cannot avoid incompatibilities with that approach, you just hide them. You could do some checking of a version number or something like that, but what do gain then compared to the wide interface?
The BIOS doesn't seem to be a good example to me. If you look at all the incompatible vendor extensions e.g. to get the memory map...

This still doesn't apply to the syscall approach because an asm programmer can make a syscall without type checking and this is a driver written for kernel level, hopefully by a capable driver coder. The kernel driver coder would have type checking thru the device header file. Also i planned for the device driver to be compiled already so its distributed as either a binary or source code. This way a user downloads the binary and the single wrapper driver (kernel specific) loads whichever manufactures device driver was needed.



The BIOS was only 1 example of this, and maybe it wasnt done right with vender extensions but it works and can be extended for purposes not thought of. The VGA card makers will add a million of them that as an OS coder i didnt know existed or that was needed for venom OS to look flash ;)

The idea was (stolen) inspired by the way VBE/AF works, but without all the pmode crap. The idea of the portable driver is for functionality not speed so if a few more type checks need to go in then put em in. Wait for the OS specfic driver to come out and drive your graphics at lightning speed.

You can't change the specification or remove a function anyway if you're not going to break compatibility. You only achieve that the compiler/linker can't shout at you if you try to do so. This is not an improvement.

And adding new functions to "real" libraries is harmless, so you don't gain anything for this case either.

Ok, I'm trying to create an EDI interface for my OS, which I will release once it's finished.

Just one thing, has anyone seen the code for the sample driver? It seems to be a utter mess of K&R C and C++ (semicolons after braces, variable initialisations in the body of code, function overloading).
<EDIT>
Also, a stack variable being returned from a function (in itself a Bad Thing (TM) ) with no mention of what can be done with it (so it is VERY likely to be trashed).
The coding style is also too compact for a sample (no whitespace in function calls).
</EDIT>

Also the specification seems to focus on what the DRIVER implements, not what the kernel must implement.

I'm might end up writing an addition to the spec. which includes the requirements for the kernel (what helper functions / classes it should implement)

Sorry if this sounds like a rant, but I think this needed to be said. Would anyone like to make a better sample driver that you don't need to spend an hour cleaning up to understand?

Edit 2: I just read the original post in the Announcements forum and saw that the sample was actually written in C++ (although it uses the .c extension)

Okay: this is it: Why don't we all create a Portable Driver Interface? I'm willing to work on it and produce a specification, seeing as I'm currently in a design phase for my kernel, and a method has pretty much presented itself to me. I haven't really read through the specification for the EDI, seeing as it doesn't really seem to have a large base of implementation.

Not only that, but for extremely original kernel designs, like mine, I assume it really isn't able to efficiently cover the requirements.

Several days ago I drafted something along these lines:

1. Drivers should be as absolutely bare-minimum as is possible.
2. Drivers, seeing as a PDI would be used on foreign system, should require very little documentation. They should be Implementation oriented, so as to allow people who incorporate them privately not to have to worry about the 'little stuff'. Therefore, the only thing that should need documentation is the INTERFACE to the driver.
3. Extending from this is the obvious need to define a set of rules that constrict the amount of complexity the interface for the driver should present.

1. A driver must only implement the bare minimum for Read/Write operations, and must always have a presentation interface for Vendor ID, etc.

2. If the driver is for a device that has extra features, these must be included in the interface documentation, and again, only the bare minimum needed to allow the Kernel to take advantage of such should be presented.

This implies that the driver simply presents a set of functions for low level manipulation of its device, and the kernel developer is responsible for making all the flashy, versatile stuff. This constraint on the amount of complexity a driver can present helps to reduce the anounf of inherent erroneous code the driver coder can produce, and places the possibility of errors in the hands of the Kernel dev'er.

Why is that a good thing? Because, if I were to take source form somewhere and use it in my kernel (which I avoid scrupulously), I want to be sure I'm not really taking a fully developed, yet buggy system. If all the driver I'm taking has are functions like open(), close(), read() and write(), getDriverInfo(), sendCommandWait(), and things like that, I'm more free to customize my system to take full advantage of the driver, as I see fit. The driver is in essence, a tool, that simple tells you that the device CAN do, but gives you no particular route that you must use to DO it.

I find this to be the absolute best method to implement driver portability. It encourages pure freedom of design.

I'm not sure how well this will be received, but I think it's for the best.

When I DO post it up, it will have good documentation, and sample code, seeing as I have ulterior motives for having done it: I intend to try to increase compatibility with my OS all round.

You can be sure it will be solid.