On Mon, 5 Jun 2000, David L. Nicol wrote:
> James Sutherland wrote:
>
> > The kernel itself would be harder, of course. Kernel modules could do
> > something similar - just unload the old one and reload the new one, taking
> > care to avoid anything trying to use the module in the mean time - leaving
> > just the core code - memory management etc., which would be much more
> > difficult.
>
> RTlinux if I am not mistaken takes the stance that the whole linux business
> is a low-priority real time process. I don't know how the rtlinux project
> has been keeping up with kernel development. But there's a partitioning
> system for you, if the RT microkernel (or whatever it is) is running
> RT processes and one linux kernel, it could run two.
How would it handle device drivers? Having two kernel device drivers each
thinking they are running on a physical machine could upset things...
The "hypervisor kernel" would probably have to handle all the device
driver aspects - PCI bus, memory, CPUs, plus any shared resources (NICs,
storage, perhaps) - but this could probably be done without too much
upheaval, I think?
The alternative would be looking at the user-mode kernel, and getting that
running as an RTLinux task without any dependence on the "real" Linux
kernel. RTLinux isn't something I'm familiar with - any thoughts on this?
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:20 EST