OS-independent driver interface. Let's start.

[Neuromancer]

First of all, hi. ;D
I opened the Mega-Tokyo forum happy to post my new creation, I read the "New Device Driver System/Architecture" post from Candamir and my happiness suddenly fell away :-\
Anyway, I am one of those ambitious people out there which try to write their own OS, but before doing so I had a idea.
I bet you all know about Project UDI and its end. Well, the idea behind this project is very good and would be a giant step for the software world: write an OS-independent device driver interface.
Its name is CAL, which stands for Common Abstraction Layer, maybe I posted something about it some times ago, but I think it's time to build something concrete.
I won't explain much about it, I've just setup a website for my projects and CAL, and a forum. If you want to know about it or contribute or give some ideas, you're welcome

www.freakz.info - Website
www.freakz.info/page.php?5 - CAL description

The only "concrete" thing about CAL are me thoughts, but I'm looking for people wanting to create this driver interface.
I won't answer anything here or on my site's forum because I'm on a 5-day holiday, so, sorry!

@ forum admins: this is no spam, really, i may be fool but i'd really like to code something like this ;D

[paulbarker]

This is the third attempt at this I've seen in a month.

Head over to the alt.os.development newsgroup and real all the discussion about Eli Gottlieb's EDI (Extensible Driver Interface) (I hope I've spelled his name right). It has headers and design documents, and is the only attempt at this I have seen which I think has a chance of suceeding.

There are 2 issues you (and Candamir) must solve before even starting:
1) Why will an OS developer choose to support your driver interface?
2) Why will a device driver developer choose to develop for your interface?

These are 2 very different questions.

If you are intending to implement it as a layer above the OS, you will need to learn the details of every kernel you wish to support in order to implement this, or find someone who knows the details who wants to implement it. You will also need to know a good bit about how these kernels work even before you begin the design.

You will need to, in both the design and implementation, demonstrate a very high level of competence. This is, sadly, the only way that people will trust the design enough to support it and code for it.

I will repeat what I said before for emphasis - look at the discussion about EDI. It is such a careful balance to not standardise too much and to not standardise enough. Hell, look at my recent discussions on here and alt.os.development about components to drop into a kernel.

I'm not saying don't do this, I would love to have a set of drivers that could be dropped straight into my OS. I'm saying make absolutely sure you know what you are doing here.

To suceed at this, you need to be a good coder, better designer and even better salesman!

Good luck,
Paul Barker

[Neuromancer]

No one should initially commercially support this project, nor should Microsoft engineers or whatever include in their system, since CAL is a _layer_ upon the current system implementation.
Anyway, there are many good DDK coders out there, I am myself a Linux kernel hacker, and have many ideas on it, many wrong, many useful. We can start coding something, writing some specs from scratch, testing and catching bugs.
What I am trying to say, is that talking about this problem and that other problem with nothing concrete, is useless.
Let me quote the signature of a user on this forum: A ship in harbour is safe, but that is not what ships are built for.
Same thing for OS development.
I'd like to talk and talk and talk about CAL, but it's 1 am here, and I need to sleep. ;D

[Brendan]

Hi,

I completely agree with Paul Barker, but I don't believe it's actually possible - especially if you plan on making it usable for all OS designs rather than a specific sub-set of OS designs.

I'd like to be proven wrong though (which has happened today already)..

So with that in mind, I've got one question. What will your device driver interface for 3D accelerated video cards look like?

Will it be like DirectX, or OpenGL, or an X server. Will it handle true 3D output devices (layered LCD screens, stereo-scopic shutter glasses, etc), SLI, shaders and GPUs. What sort of overhead would it have.

If you can answer this (admittedly complex) question with a clear, concise, plausible and descriptive answer, then you might have a chance....

I also need to point out that starting by coding something is the worst possible way to start - research, then design, then research, then design, then double check the design and the research, then document the design completely, then do a "market survey" to see if anyone wants what you've designed (and don't think about coding until all of that has been done).


Cheers,

Brendan

[Candamir]

I didn't know there was anyone else out there researching in the same topic as me ;D. @Neuromancer: I think I'll shortly register myself in your forum so that we can continue our research over there.

Well, I think the base for the design is laid in the other topic (New Device Driver System/Architecture). Obviously, Brendan is more than right and we had first to improve this design on paper before actually start coding...

@Neuromancer: For the coding part, I think we should start off with a small kernel that handles just what we need it to handle. These requirements would obviously be based on our design.

[octavio]

If somebody wants to make a standard drive interface,it must
start by writing a lot of drivers, so it will know what he is talking about, and people will use this spec because there are some drivers already written to demostrate the good design of the specs.

[Solar]

Just for completeness sake, the UDI bot...

http://www.projectudi.org

[Pype.Clicker]

to add yet another "source" of info, the super-network-card i'm working on at the moment (read, Intel IXP2400 network processor) comes with a SDK where driver sources are made "OS independent" by the mean of an OS abstraction layer (that is, a library defined by the driver vendor that hides the details of OS programming).

And you might (or not) be surprised to know that the driver sometimes fork kernel threads of its own to handle packets, or it has to create and manage pools of buffers, manipulate in-kernel mappings, etc. And it has to cope with the fact that some OSes do not have multiple address space or that some do not protect the kernel datas from user programs (yes, that still exists: in embedded OS such as VxWorks, for instance).

Yet, a more general framework (something like an unified driver development kit) might be interresting for the driver developers if you can come with two version: one for development that can somehow "sandbox" what the driver does, and a production version that is shipped by the vendor.