OSNews

A driver written in Java is not yet a driver being cross-platform. It is bound to the interface provided by the operating system.

The Java driver infrastructure provides a set of abstract classes and interfaces that the driver developer needs to extend/implement; so, the infrastructure is very tied to the underlying OS, but the classes and interfaces provided not.

No, it's humour .

"What the heck does that mean? Are you sure you don't mean "infamy?""

It's called wit. I understand a lot of geeks lack it.

I thought it was kind of clever.

Don't be so damned smug. It usually comes off making you look like a fool.

60-something people read it. Hardly anonymity, but certainly not especially witty.

"The only nitpick I have is that the name EDI already has a meaning (Electronic Data Interchange - ANSI X12).

Maybe you should call it XDI instead? It has an 'X' in it, so it has to be cool, right?"

Eerr... http://en.wikipedia.org/wiki/XDI, http://www.xdi.org etc. I guess any three letter acronym is used somewhere, as long as the context is clear, it's no problem, imho.

Edited 2006-12-05 09:54

I have to admit, it works pretty well for Syllable. You don't have to implement a complete Linux API either; Linux tends to offer a whole bunch of little macros and functions that tend to do very simple things, and you can actually do without a lot of it. You can still make larger structural changes to your kernel and still maintain a fair level of compatibility with the important parts of the Linux API's. Something like a spinlock can only be implemented so many ways, or a set of atomic operations, for example.

Now that's not to say that something like EDI couldn't make things even easier, but I suspect the API's would eventually end up looking pretty similar to existing systems.

There are a couple of reasons not to implement Linux APIs:

1.If you mean Linux's user-mode API, I think it likely that device drivers will *implement* file system operations and should therefore not rely upon them.

2.If you mean Linux's in-kernel driver API, it can't be emulated or implemented because it doesn't exist. Linux's internal driver code runs on a continuous ad-hoc agreement between kernel hackers and driver developers, utterly without a specified API.

As we're discussing driver development, I'm talking about the API between the driver and the kernel. Yes, Linux does have one. It may technically comprise every single function and table in the entire kernel, but it is still an API.

The thing is, you don't need to emulate every single Linux kernel function. You just need to support some areas of functionality in a way that is close enough to the way Linux does them that you can port a driver from Linux with a few small changes. This is exactly how Syllable does it; there is a well defined driver API, but where functionality intercepts with Linux the implementations are similiar.

For example our atomic functions are almost identical, because there's only so many ways to implement an atomic increment operation on IA32, so why not just do it the same way? Memory management, mutexes: all of the low level functionality, is similiar enough to Linux that it's easy to port a driver. This sort of stuff doesn't change often within Linux.

The few places where implementing Linux functionality would be cumbersome are covered by a simple system header file "linux_compat.h" which wraps Syllable functionality to present a set of functions and macros that work well enough to be used with a lot of Linux drivers.

So yes, it can be done and we're doing it. Not only are we doing it, but it is in fact working out very well for us!

>As we're discussing driver development, I'm talking about the API between the driver and the kernel. Yes, Linux does have one. It may technically comprise every single function and table in the entire kernel, but it is still an API.

Except that implementing Linux's driver API also requires that drivers code for a monolithic kernel. Oops, there go all those interesting microkernel projects where the drivers can't access symbols inside the kernel.

Linux's driver API also can't work on microkernels because you would have to code a runtime driver API layer that polled "kernel variables" in order to send messages to the real kernel. Probably technically possible, but very hard and not likely to happen.

EDI, in contrast, requires only functionality that a user-mode library could translate into messages or even implement itself.

Edited 2006-12-01 15:43

The archive seems to have had its line endings changed (been eaten by mingw or cygwin, perhaps?). I've put up a fixed version at http://www.8325.org/EDI-3.4.tar.bz2.

Edited 2006-12-01 00:07

Well it's supposed to be on sourceforge.net.

http://sourceforge.net/project/showfiles.php?group_id=148100&packag...

However, I've tried several mirrors so far and the EDI archive is utterly corrupted. Ugh.

Same here, download is corrupted and appears empty.

I'm very interested in looking into this though. A few years ago I too read the UDI specifications (of which there are hundreds of pages of it) in high hopes of making my fledgling OS interact with others, but eventually discarded it as the author did after realizing the sheer magnitude of the specification and what all was required. The idea of someone creating a similar but simpler idea is very appealing.

Are you talking about Project UDI? The defunct Project UDI that got abandoned by its industry sponsors because it was as bloated as CORBA and requires implementation of almost a whole virtual machine?

Maybe we could use a CORBA interface between the driver and the OS, so that the interface would be truly language independent.
;-)

My "suggestion" was just there to show that if you try to provide an API which would work for also for a Java, Haskell OS, there is a real possibility that the result is an unusable monster..
Solving the driver problem for OS which can interoperate with C easily looks good enough to me.

Thanks... that's what I'm trying to say. There is already some hardware documentation, but it's often leaky, and I know of no central point to get it all. Ralph Brown's "interrupt list" is the best I know, but I think many new HW pieces are not described there.