Robert Millan <[EMAIL PROTECTED]> writes: > glad to hear. do you think it's pointful to implement it in Mach so we > can use interrupts instead of polling from now on?
I haven't looked at all at Mach interrupt handling. If it's easy to implement intwait (did I understand you correctly that intwait is an existing interface on some system?), than that seems like a reasonable tool to start with. What one needs is some server (inside or outside of the kernel) that can send a message to the driver when an interrupt occurs. But if it's hairy to do in Mach, then it's probably not worth the effort. > > Besides functions like ioperm and intwait, I guess it would be nice > > with some other more frameworkish things, like managing who can and > > will serve each interrupt, but you don't need any of that until there > > are a dozen or so of different drivers that need to cooperate, so that > > can be an independent project. > > are you sure? I'm pretty that the above is my personal opinion ;-) I mean, one can start designing a framework and discuss for months what's the best way of organizing things (see the networking discussion we had a while back). And given the framework, one can start writing drivers. That approach may work fine if the involved people have a lot of experience in doing the kind of stuff that the framework is supposed to support. However, I suspect that's not the case with Hurd user-level drivers. Then the opposite approach, to start with simple drivers and then some more complicated drivers, can be a very good way to discover what a good framework should look like. That makes it easier to get the design right. Most frameworkish things won't get even close to doing the right thing until the second or third rewrite. And one can hack on the drivers and the framework in parallell, when you have enough drivers that they need to cooperate, it's time to use or construct that part of the framework. /Niels _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd