> Is it possible to dispatch/register more than one interrupt?
Yes. That's part of what make this model so much more flexible
than the other one. handleInterupt() is declared with an int parameter,
which is the interrupt number, so you can check which one fired.
> The fdc-driver (not event based) has 2 lines in "handleInterrupt" I hope
> that is not time critical. Or does this driver has to be event based too?
The event basis is just to notify you about the interrupt. Two
lines is actually quite a bit less than what the keyboard driver has right
now (it loops over the keyboard controller until it stops sending new
scancodes), but that's because the the driver would miss data otherwise.
To make it clear: I have removed the wait()-based model while implementing
this one (they aren't really compatible). If you choose to use some other
model internally in your code, it shouldn't really matter that much; your
handleInterrupt() method would just update the varibles your driver thread
is looking at. (For instance, the driver thread could .wait() on
something in the driver object, to be notified() by handleInterrupt().)
> The "jos.platform.driver.screen" function is hooked into
> classpath ,probably with the reflection-class, and will decide which
> driver to load (Vga,Matrox or whatever) and there will also be
> jos.platform.driver.networt, jos.platform.driver.hd,....
Right. If we know that a particular platform object will need
different drivers on a finer-grained level than platform (i386/host/etc),
it can be constructed such that jos.platform.driver.screen is an object
factory, returning driver objects as appropriate. The drivers could, for
instance, all be implemented against the JavaOS/B specs without changing
the appearance of the JOSBox (or whatever). Sub-packages of jos.platform
are OK, too, if we need them.
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
