Linked by Eli Gottlieb on Thu 30th Nov 2006 17:42 UTC
OSNews, Generic OSes On December 28th, 2005 - a day which will live in anonymity - OSNews published an editorial of mine urging hobby and research operating system developers to implement Project UDI, because otherwise we (the small/ non-mainstream/ hobby/research OS community) would always wind up stuck with mutually incompatible sets of drivers for doing the same exact things. I also proclaimed that I would implement UDI for my own operating system kernel. Bad decision.
Order by: Score:
Java Drivers?
by FunkyELF on Thu 30th Nov 2006 18:12 UTC
FunkyELF
Member since:
2006-07-26

Wasn't there an article somewhere about someone implementing a Solaris driver in Java?

Now that Java is going to be open it would be nice.

Well, except that even if Nvidia, ATI, Netgear, or whoever could write one driver that could potentially work with 20 operating systems they wouldn't because Java can be decompiled pretty easily.

Reply Score: 1

RE: Java Drivers?
by Ford Prefect on Thu 30th Nov 2006 18:35 UTC in reply to "Java Drivers?"
Ford Prefect Member since:
2006-01-16

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

Reply Score: 4

RE[2]: Java Drivers?
by ebasconp on Thu 30th Nov 2006 19:53 UTC in reply to "RE: Java Drivers?"
ebasconp Member since:
2006-05-09

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.

Reply Score: 2

Eh...what?
by Adam S on Thu 30th Nov 2006 18:20 UTC
Adam S
Member since:
2005-04-01

a day which will live in anonymity

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

On topic, though, I would love to see this become a reality. A large part of why some new OSes don't get off the ground is because they work on such limited hardware.

Reply Score: 1

RE: Eh...what?
by Thom_Holwerda on Thu 30th Nov 2006 18:21 UTC in reply to "Eh...what?"
Thom_Holwerda Member since:
2005-06-29

No, it's humour ;) .

Reply Score: 2

RE: Eh...what?
by llanitedave on Fri 1st Dec 2006 05:19 UTC in reply to "Eh...what?"
llanitedave Member since:
2005-07-24

"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.

Reply Score: 1

RE[2]: Eh...what?
by Adam S on Fri 1st Dec 2006 12:24 UTC in reply to "RE: Eh...what?"
Adam S Member since:
2005-04-01

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.

Reply Score: 1

EDI
by mallard on Thu 30th Nov 2006 18:35 UTC
mallard
Member since:
2006-01-06

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?

Reply Score: 4

RE: EDI
by jal_ on Tue 5th Dec 2006 09:52 UTC in reply to "EDI"
jal_ Member since:
2006-11-02

"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

Reply Score: 1

why not...
by diegocg on Thu 30th Nov 2006 18:41 UTC
diegocg
Member since:
2005-07-08

implement a set of APIs that mimics Linux's APIs?

(Yes, Linux changes very fast, but then you're not forced to follow absolutely all the kernels)

Reply Score: 1

RE: why not...
by Vanders on Thu 30th Nov 2006 20:05 UTC in reply to "why not..."
Vanders Member since:
2005-07-06

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.

Reply Score: 5

RE[2]: why not...
by EliGottlieb on Fri 1st Dec 2006 05:40 UTC in reply to "RE: why not..."
EliGottlieb Member since:
2005-10-30

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.

Reply Score: 3

RE[3]: why not...
by Vanders on Fri 1st Dec 2006 08:00 UTC in reply to "RE[2]: why not..."
Vanders Member since:
2005-07-06

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!

Reply Score: 3

RE[4]: why not...
by EliGottlieb on Fri 1st Dec 2006 15:26 UTC in reply to "RE[3]: why not..."
EliGottlieb Member since:
2005-10-30

>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

Reply Score: 2

RE[5]: why not...
by Vanders on Sat 2nd Dec 2006 11:34 UTC in reply to "RE[4]: why not..."
Vanders Member since:
2005-07-06

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.

I don't see how this is relevent. The situation is identical on Syllable: a driver can not access symbols inside the kernel unless they are made available via. the kernel API (O.K, sure, the driver shares the same memory space as the kernel so you could hack your way around it, but that's irelivent to this discussion)

Linux's driver API also can't work on microkernels..

Agreed. Getting it to work would be possible but you'd have to make a lot of compromises. Although doesn't HURD try to offer some sort of Linux-like driver API?

Reply Score: 1

RE[6]: why not...
by EliGottlieb on Sat 2nd Dec 2006 19:22 UTC in reply to "RE[5]: why not..."
EliGottlieb Member since:
2005-10-30

I don't see how this is relevent. The situation is identical on Syllable: a driver can not access symbols inside the kernel unless they are made available via. the kernel API (O.K, sure, the driver shares the same memory space as the kernel so you could hack your way around it, but that's irelivent to this discussion)

Except that not all systems have the driver share memory spaces with the kernel. A good driver interface doesn't impose design decisions on operating system developers.

Although doesn't HURD try to offer some sort of Linux-like driver API?

At that point you might as well implement EDI, which will run fine on a microkernel with hacks and crocks to imitate drivers existing in the kernel's address space on a microkernel, where keeping drivers out of the kernel is a conscious goal.

Furthermore, I don't see exactly why Linux's driver API is all that great. Imitating it on systems which don't deliberately imitate Linux (as Syllable does) would have the same effect that porting C and Unix to every single hardware platform did: You wind up with too many mutually incompatible versions of the same thing, none of which were actually designed well for their task, all created in the name of portability.

That is what you get from standardizing on big interfaces.

Edited 2006-12-02 19:23

Reply Score: 2

3D support
by Touvan on Thu 30th Nov 2006 19:41 UTC
Touvan
Member since:
2006-09-01

I didn't understand the technical details of this entirely (slightly over my head) but could this be used to write a driver for 3d hardware that protects the trade secrets and whatnot, that can be combined with the other half of the driver - the OS half, so that a single binary object (per ABI and hardware platform of course) could be compiled into many OSs (like Linux, Windows, Haiku, etc.)?

It would be awesome if there could be at least some practical separation (even if it isn't necessary or enforced) between the hardware side and the OS side (I assume that's what this is all about, but I've been wrong before) that would allow the hardware manufacturers to guard their precious (mostly hardware related) secrets by releasing the compiled libraries that go with their hardware, while allowing the OS part of the driver to be Open Source, for all to port and poke at.

Even better if there is an easy tool kit that will help hardware makers write their drivers to run on all of Linux, Windows and Mac OS X.

Reply Score: 1

Archive corrupted?
by Luke McCarthy on Thu 30th Nov 2006 19:44 UTC
Luke McCarthy
Member since:
2005-07-06

I downloaded the headers, but they fail to decompress.

Reply Score: 1

RE: Archive corrupted?
by nick8325 on Fri 1st Dec 2006 00:06 UTC in reply to "Archive corrupted?"
nick8325 Member since:
2005-10-06

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

Reply Score: 2

Whre is the code?
by vadim on Thu 30th Nov 2006 21:22 UTC
vadim
Member since:
2006-11-30

Please, somebody managed to find the URL for the code?


Thanks

Edited 2006-11-30 21:22

Reply Score: 1

RE: Whre is the code?
by bnolsen on Thu 30th Nov 2006 23:38 UTC in reply to "Whre is the code?"
bnolsen Member since:
2006-01-06

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.

Reply Score: 1

RE: Where is the code?
by Nairou on Thu 30th Nov 2006 23:46 UTC in reply to "RE: Whre is the code?"
Nairou Member since:
2006-07-06

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.

Reply Score: 2

Code link and corrupted archive
by EliGottlieb on Fri 1st Dec 2006 05:34 UTC
EliGottlieb
Member since:
2005-10-30

Hiya all.

First of all, the archive is indeed corrupted. Sourceforge seems to eat every tarball I upload to them. I sent a new one to no avail. Anyone know a better hosting site for a broke high-school senior's coding projects? It also ate my kernel release.

nick8325's fixed mirror at http://www.8325.org/EDI-3.4.tar.bz2 works. I don't know what I'd do without kind guys like Nick. http://www.mytempdir.com/1092730 will also work. I don't know what to do about the official link in the article.

I hate Sourceforge. They never remember my password correctly, and now they require that everyone dos2unix (or the reverse?) source tarballs.

This is not at all what I hoped for the public introduction and release of EDI.

Edited 2006-12-01 05:43

Reply Score: 2

But project UDI..
by fithisux on Fri 1st Dec 2006 10:40 UTC
fithisux
Member since:
2006-01-22

is OSS, can be revitalized and there can be a licence where driver developers on UDI should give their source code. UDI is not for trade secrets, its for ease of development of OSS drivers. Imagine you have to write a different FireWire or BlueTooth stack for Linux/OpenBSD Haiku? Wasted effort. But UDI can help and is extensible. I think I should make a closer look.

Reply Score: 1

RE: But project UDI..
by EliGottlieb on Fri 1st Dec 2006 15:45 UTC in reply to "But project UDI.."
EliGottlieb Member since:
2005-10-30

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?

Reply Score: 2

for ALL operating systems?
by Morin on Fri 1st Dec 2006 10:49 UTC
Morin
Member since:
2005-12-31

I have looked at the specification, and UDI looks very C-based. How is this going to work with JNode (Java-based), House (Haskell-based) or any other OS that des not use the Unix paradigm of kernel, processes, address spaces, and so on?

It seems to me like this is going to hit the same trap os OSKit and OSLib did: Too specific to one way of thinking. If you want to restrict programmers so tightly, why not just write the final OS?

And this one too shows what I am talking about:

> EDI also calls for a partial implementation of POSIX threading, and
> allows drivers to take advantage of multithreading. I'm very sorry about
> having to standardize this, but most systems implement some kind of
> threading and many drivers require it.

C'mon, POSIX threading in a Haskell-based OS?

We need an aproach that is *independent* from the OSes where it is going to be used.

Reply Score: 2

RE: for ALL operating systems?
by renox on Fri 1st Dec 2006 11:27 UTC in reply to "for ALL operating systems?"
renox Member since:
2005-07-06

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.

Reply Score: 2

Hardware documentation is more important.
by axilmar on Fri 1st Dec 2006 13:49 UTC
axilmar
Member since:
2006-03-20

Drivers can not be O/S-agnostic because each one is tailored to the needs of the operating system is about to run on...but perhaps if there was a central site will cleanly written documentation on hardware, the problem of drivers would not exist.

Reply Score: 1

Morin Member since:
2005-12-31

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.

Reply Score: 1