Jeff,
I know last time I mentioned this you pointed me to how you are currently
getting around IRQ handling.
I would like to propose adding interrupt handling to the UM kernel. Being that
UM is an attempt to provide a exvironment to developers that mimics the Linux
kernel as close a possible (yet maintaining the level of protection provided
by running in userland) we should try to make the implementation of emulated
hardware as similar to a native kernel as possible. Currently anytime input
is coming from outside of the UM it is received by a UM stub which then makes a
call into the UM kernel via a UM kernel function. In the native Linux kernel
this type of activity is done via system calls (from the userland) and
interrupts (from the hardware). Jeff has done a great job of keeping the
system call path as similar to a native kernel as possible. This is good
because a developer can realistically implement a new system call, and only
needs to take into account a couple of UM related issue, but other then that
the system call implementation should portable over to any plateform (with
minimal plateform specific gunk). I think we can do the same think for
interrupts. By using an interrupt based environament we now force developers
to respect IRQ masking and the fact that IRQs can spring up at any time. This
will provide developers a more realistc environemt to test new software.
ranted a developer will not be able to write a hardware driver in a UM and
them magically have it work on a native kernel, but a file system developer will
be forced to deal with interrupts even when developing in the UM. So in
theory the UM implementation of a file system can be directly ported to a
native kernel.
If we do add interrupt handling, we can take it a step further and provide
useful debugging of interrupt handling. We could write logging routins that
tell when and where interrupts occured, and using this the developer can
figure out where to mask interrupts.
Any comments?
Jim
--
James R. Leu
|
