> > It's not yet clear wether we should stick to Mach's device API > > or if the oskit-mach people are considering a totally new approach. > > Basically, the drivers must be implemented in user-space (L4 API > > sends INTs to driver threads through IPC, much like in Mach). > > The Mach device interface is open, read, write, close, I don't see how you > can have anything else. The details are almost insignificant, it's trivial > to go from one interface to another. With one exception, and that is the > terminal interface. Luckily, the braindead Mach terminal interface is > completely encapsulated in term/device.c (or something like that), and you > just need to rewrite this file if you use a saner semantics.
Right. I didn't mean the Mach <-> user-space dev_*() interface you mentioned above (that is easy), but rather the (future) interface between L4 (and Mach?) and the user-space drivers. Things like passing INTs to the drivers or clearing them, locking w. cli/sti etc... > I suggest to work on putting OSKit drivers into user space now, and try to > get it working with Mach and/or L4. Waiting for L4Env is probably not so > good an idea before we know more about it (it might after all never really > mature, while OSKit has a lot of drivers already and works quite well). That is a very good idea indeed. We could start with a few essential drivers like: serial, keyboard, vga, and probably atapi/disk. Any takers? -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]