Re: New thoughts about deva/fabrica

[Bas Wijnen]

On Wed, Aug 17, 2005 at 10:36:11AM +0200, ness wrote:
> [I hope I'm not too late...]

This was the reason I haven't replied before, as I also recently worked my way
through a long time of archive.

> After I read antrik's proposal about "posix level device drivers" I 
> thought that was a great idea. I spent the last 3 days reading mailing 
> list archives, and now I'm unsure it is.

I also thought so initially, and I mostly still do.

> Actually, most of the advantages listed there can be implememted in the
> original ddf proposal by Peter De Schrijver and Daniel Wagner.

I don't think so.  The idea as far as I understood it was to allow device
drivers to use posix and hurd features.  That is prohibited by the "OS
independant" approach.

> Second, while readin' the 
> mailing list it tourned out for me that there're lots of disadvantages 
> we have with posix level drivers, and not the smallest one is speed. 

Device drivers are not required to use the posix features.  Some drivers, such
as the USB bus driver, will be used a lot, and every optimisation in them is
worthwhile.  Such drivers should not use posix features if it slows them down.
But if I (as a user) want to write a driver for an unsupported device, it
would be very nice indeed if I'm not required to live with a restricted
environment.  This is exactly the reason why I don't do so much kernel hacking
on Linux.  The stuff is annoying to write and annoying to debug.

Of course the hurd is much less restricted by those problems, because many
things which are drivers in Linux are translators here, but I would very much
like to also allow core drivers to be "normal" translators.  However, only as
long as it doesn't hurt performance.  That is, if allowing this causes severe
performance penalties for drivers which _don't_ make use of it, then it
shouldn't be done, in my opinion.

> Third, if u have a look at "conventional" drivers, there's no or very 
> less need of libc functions.

That's because they're not allowed to be used from there. ;-)  I would add a
network server to my Linux device drivers for debugging or controlling if I'd
be allowed by Linux.  But I'm not, so I don't use all the libc calls for
networking.  I don't have a real idea of what I'd use if everything was
allowed, but I think it would be quite a lot.

> And fourth, there's a pragmatic reason: a 
> microkernel allows to run multiple OS in parallel. And we shouldn't skip 
> this great advantage. But I don't see a way to marry posix level drivers 
> and OS independend drivers.
<skip explanation>

I don't agree with you here.  Our first priority should now be to get a
working system (on L4).  I feel it's hard to contribute to the project at the
moment because I can't write or port "normal" programs.  I've heard from
others they're also waiting until the system has some device drivers.  I think
we really shouldn't delay ourselves even more by trying to add extra features
which most people will not use.

I think we should get some code written as soon as possible.  Then we can see
what works.  I feel we should allow posix drivers, because it greatly
simplifies the task of device driver writers.  For drivers which really need
it, we can (possibly later) write them without those features.

Perhaps it will later be very hard to make running multiple OSs possible.
Perhaps a new ddf needs to be written for it.  That may take years.  But if we
want to allow it now, it may also take years, and as an extra "bonus", it will
prevent some people from writing drivers for us, because they feel it's too
restrictive.

Needless to say, I don't feel that the benefit of allowing multiple OSs is
worth those costs.

Now let's get some code written. :-)  (which doesn't mean we shouldn't discuss
about it as well)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature