Hi Todd and all
On Tue, 26 Oct 1999, Todd L. Miller wrote:
> Went with the hybrid proposal, and it works perfectly (AFAIT*) on
> the host now. I'll try to test the i386 boot out sometime tonight. The
> native code support is activated with the -DNEW_INTERRUPT_HANDLING flag,
> but the bytecode support is radically different, to the extent that I had
> to make a new bytecode tree and compile against that. Once I bring that
> tree up to snuff, I'll just move into where the old tree was and finally
> do a CVS commit and the thing.
great I'll take a look at it.
> Driver writers: the new interrupt paradigm is straight
> event-based, with jos.system.interrupts using addInterruptListener() in
> the usual way, with one exeption. When the interpreter finishes the
> current timeslice, it checks the interrupt queue; while it's not empty,
> the C code will extract your driver objects from jos.system.interrupts and
> run its handleInterrupt ( int interrupt_number ) code from there. This
> code will run, uninterrupted -- including by other interrupts -- until it
> completes, so be very careful with it. Get your data from the h/w in that
> function and let another thread take care of the analysis, if at all
> possible. (The keyboard driver, for instance, (will) slurps scancodes out
> of the controller and shoves them into a queue, where the keyboard daemon
> can play with them, distribute them, etc.)
Is it possible to dispatch/register more than one interrupt?
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?
> My model, in general, is that jos.platform.* is limited to
> abstractions common across every computer JOS will run on, like keyboards
> (even if they aren't there). jos.platform.keyboard generates Key and
> Scancode events, but jos.platform.driver.keyboard (& keyboardd) is what
> handles the hardware (lower-edge) part of the driver. The
> platform.drivers are expected to use jos.system.* (probably should be
> renamed) to access the h/w, via the interrupts and machine classes, and
> more as we need them.
>
> Thus jos.platform.screen would be driven by
> jos.platform.driver.screen, which would just be Thomas Bocek's VGA driver
> class (or a wrapper there-to). jos.platform.driver.* will be copied over
> from arch/bytecode/jos/platform/driver/* according the current build, so
> that's how we get h/w-specificity.
[cut]
some more questions:
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,....
Thomas Bocek
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
