Re: userspace drivers

[Niels Möller]

Robert Millan <zeratul2@wanadoo.es> 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