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.
Thread beginning with comment 186836
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: why not...
by Vanders on Thu 30th Nov 2006 20:05 UTC in reply to "why not..."
Member since:

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 Parent Score: 5

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

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 Parent Score: 3

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

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 Parent Score: 3