[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New thoughts about deva/fabrica

From: ness
Subject: New thoughts about deva/fabrica
Date: Wed, 17 Aug 2005 10:36:11 +0200
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050813)

[I hope I'm not too late...]
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. Actually, most of the advantages listed there can be implememted in the original ddf proposal by Peter De Schrijver and Daniel Wagner. 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. Third, if u have a look at "conventional" drivers, there's no or very less need of libc functions. 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. And we need OS independend drivers, as they have to control multiple/parallel access. Actually, we're not able to run multiple OS, but that's not the problem. We CAN run multiple OS with little changes (make wortel boot 'em, and implement "our" physmem as a proxy to the global physmem). But if we want to keep the ddf OS independend, this has to be planned from the beginning. (The original proposal looks like it is.) The most important thing we'd have to consider is the management of multiple deva. Actually, it's a question of trust:
The ddf only trusts
a) itself
b) wortel
c) all deva
I'd propose an global wrapping server (as part of the ddf). It should
a) only communicate with wortel
b) wrap thread/task management (or should be notified at the creation)
c) be notified at task deletion (sth. like our task info caps)
d) based on c) export a task death notification system for parts of the ddf (this is essential for securety of w0 and o0, se next paragraph) e) give information whether a task is trustable or not (is part of ddf || is wortel || is a registered deva) So it's main job is interaction between the ddf and the manager OS (wortel). All communication with the OS(') is done through (their) deva. Communication is mainly loading new drivers. So if a new device is found, the plm has to ask all deva. So the main difference between my ideas and the original proposal is the strict severance between the manager OS (that is exactly 1 time runnin') and the real OS' (that are 1+ running). We need well-defined protocols ddf <-> wortel And ddf <-> deva. Second, I'd like to inspire beside the central IRQ server w0 a central port-I/O server o0 (omikron-zero). I see the following advantages: locking of ports, easy access (via inb/outb, inw/outw ...), and mapping if very fast access is needed. I'd be happy to implement both of 'em and write an interface specification for the second. Of course this would need more discussion, first, but I hope we don't get stuck in endless discussions.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]