EDI-3.3 released

[Crazed123]

Tarball is available at: http://prdownloads.sourceforge.net/glider-kernel/EDI-3.3.tar.bz2?download

OK, here're the updates: I've switched to a subset of POSIX threads, though the definitions and things are a little rough around the edges due to unclear manuals. EDI now also uses a full function-calling model for drivers, with the kernel starting a driver via its driver_init() function, using it by calling driver objects, and calling driver_finish() on shut down. It's fully allowed for microkernels to link the driver to a stub (which the driver will think is the kernel) that will perform the appropriate message-passing to implement the EDI interface.

Also, the driver initialization has changed so that the kernel can (if it wants) pass the driver a list of EDI objects for it to use. The driver can also call edi_negotiate_resources() if it wants more or different objects, but the decision of whether to grant them (ie: just let the driver try to create resources as it wants (since the kernel can always veto a creation or initialization of an object)) ultimately lies with the kernel. For kernels with hardware managers or whatnot that detect hardware and assign resources to the driver, this is a boon. Kernels that don't hand the driver resources must allow resource creation by the driver by returning true from any call to edi_negotiate_resources().

As I said, POSIX threading is a little rough. I'm somewhat stumped on where exactly the pthread_mutex_t and other structures should actually be defined. One major thing I'll note is that any functionality which is optional under POSIX is optional under EDI, with the exception of mutex error-checking. Undefined behavior is a no-no.

Lastly, there's no example driver in this version, console or otherwise. I could have taken the time to research and write one, but "release early, release often"!

[edit]This is not just an announcement topic. 75 people have viewed this thing, so if anyone has something to say on EDI, SAY IT HERE![/edit]

[Crazed123]

1.BUMP

I have a proposal to make. This Sunday, I'm leaving for camp and won't come back until early to mid August. However, I'm at the point where I could implement EDI for my own kernel. If anyone wants to respond to this, I shall begin to do so, and the next EDI revision will include some pseudo-sources (psuedo in the sense of making "system calls" to my underlying kernel functions) to a reference implementation.

In short, would somebody *please* say whatever they think about EDI? At 115 views somebody has read this topic. I can't incorporate your input without your input. And if nobody wants any improvements, then it's time to evaluate EDI for possible use in our actual operating systems.

Oh, and I'm uploading a new tarball (to the same location) that states explicitly the fact that EDI is under the GNU Free Documentation License.

[chasetec]

I think EDI sounds like it has something to do with device drivers and it comes in a tarball.

Is there a thread or some docs that tell me what it is?

[Cjmovie]

A tarball is like a zip-file for source code (or anything else, but usually code), with no compression, to start off. So it's like a folder, but it's a file. Usually then compressed with eg. bz2.

EDI is a specification for people to write drivers in a way that they can be used in any operating system supporting EDI, so a you A) only have to write a driver for your hardware product only once for all systems supporting EDI and B) Any OS supporting EDI has a large (hopefuly) driver base.

Of course, I don't think ANY hardware vendors currently plan on supporting EDI, so it'll all be done by the userbase if it ever gets to that point .

Also, Crazed123, if you have the time I don't see the point in _not_ supporting it, as if it ever does get put to use it'll be a good source for drivers in your OS.

(FYI, I didn't look any of this up so chances are I'm wrong in at least 1 thing....)

[Pype.Clicker]

i had a look at the EDI framework yesterday and was surprised about all the "object model" you've put there. somehow it comforts me in the feeling that what we need is a sort of ABI for expressing what the driver requires ...

I guess i'll find more about how EDI abstract kernel functions for the driver (and driver functions for the kernel) when i'll dedicate more time to this (i just had a q&d look)...

[Crazed123]

A tarball is like a zip-file for source code (or anything else, but usually code), with no compression, to start off. So it's like a folder, but it's a file. Usually then compressed with eg. bz2.

EDI is a specification for people to write drivers in a way that they can be used in any operating system supporting EDI, so a you A) only have to write a driver for your hardware product only once for all systems supporting EDI and B) Any OS supporting EDI has a large (hopefuly) driver base.

Of course, I don't think ANY hardware vendors currently plan on supporting EDI, so it'll all be done by the userbase if it ever gets to that point .

Also, Crazed123, if you have the time I don't see the point in _not_ supporting it, as if it ever does get put to use it'll be a good source for drivers in your OS.

(FYI, I didn't look any of this up so chances are I'm wrong in at least 1 thing....)

The only point in not supporting it would be if nobody else supported it. A 1-system, 1-man driver abstraction interface is really just another "proprietary" driver interface, and isn't much good for making drivers portable.

Pype.Clicker: Initially, EDI didn't run on an object model. However, after talking with froggey (and a couple other guys AFAIR) on IRC, it seemed that a class/object system would best provide the "extensible" part. However, if you have a better idea I'm open to it.

Chase@OSDev: The tarball contains, in addition to headers, documentation in HTML and Latex formats. Doxygen (and its ilk for other languages) is a freaking miracle.

[chasetec]

A tarball is like a zip-file for source code (or anything else, but usually code), with no compression, to start off. So it's like a folder, but it's a file. Usually then compressed with eg. bz2.

Did you really just describe a tarball on an OSDev forum? Thanks but I was asking about EDI itself.

[chasetec]

Chase@OSDev: The tarball contains, in addition to headers, documentation in HTML and Latex formats. Doxygen (and its ilk for other languages) is a freaking miracle.

Cool, so someone made Javadoc for C.

Reading through just a little bit it sounds really familiar in purpose. What makes it significantly different then UDI?

[0Scoder]

One thing I might ask you to add to the documentation is an example driver written in c - it'd make things alot easier for those of us with little c++ experience! EDI isn't c++ specific is it?

[edit]
- Should have said before - I really do like the look of EDI, and I'll have to study it in more detail! I'm pretty sure I'll implement it if my kernel ever gets to that stage
- I see now that it isn't c++ specific - the documentation just talkss alot about classes!

[Crazed123]

An example driver in C? I'll get to it in August when I'm back from camp. The old example driver was in C++, and the newer one was going to be, as well. Most of the point of using C++ was to demonstrate how it's possible to neatly map a C++ class onto an EDI class. Feh.

The biggest differences between EDI and UDI are:
1.EDI is designed to be source-portable given an API, unless an operating system *wants* to require some extension class (in which case it's really that OSdever's problem that they require a cryptographic message-passing extension or whatnot). EDI will never force an OSdever to write a virtualization layer in order to be compatible. EVER.
2.Talking about those extension classes, EDI is supposed to allow and encourage them. After all, if everyone does everything *entirely* the same way then we're not really writing different systems, are we? For example, the only two classes implemented by the driver that I guarantee I'll standardize will be block and character devices. A few other "device type" classes will probably make it in, but specifying exactly how USB device drivers talk to the bus driver will be up to developers.

On that topic, there *does* have to be some way for certain drivers to talk to each other. This one I'm leaving entirely up to you guys, IPC is always a very preferential topic. Or maybe there doesn't. The simplest thing that works.

[Candy]

The common standards have either two choices (yes, I'm seeing this as black&white):

You either define a common interface for OS interaction, or you don't, or you define all possible interfaces simultaneously.

If you do, you're forcing me to use a similar interface to yours which I dislike (I'm for designing myself).

If you don't, I can't interface with the driver so it's a pointless driver.

If you define all possible ones, I'm going to have to support them all for all drivers to work - or - drivers are going to have to implement them all for them to work in all OSes.

Damned if you do, damned if you don't.

[Crazed123]

I think, since the OS development community is currently rather small, that device types/driver classes could be standardized through community discussion the way RFCs are.

[astrocrep]

To be honest, I have yet to look into the source.

But to me it sounds like it has potential...

Why do we need 2^32 different floppy drivers?

But the big this is proof of concept.

Does your source include any drivers that could be dropped right in to your framework?

-Rich

[Crazed123]

The last version had a text-graphics driver. The next release will have, if I remember the plan correctly, a serial port driver.