On 3/13/06, Nakajima, Jun <jun.nakajima@xxxxxxxxx> wrote:
> For the "mini guest", I think it could be much easier if we
> substantially strip down xenlinux rather than adding (eventually) a lot
> of stuff to the current mini-os, mainly because we need probably a
> multi-threaded run-time environment, scheduler, memory allocator, event
> handling, drivers such as xenbus/netfront/blkfront, etc. At least, I
> think we can use xenlinux as the development platform. For example,
> implement the qemu-dm as a driver adding the infrastructure required
> (e.g. small in-kernel glibc).
It seems to me the main reason we needs threads and scheduling is to
interact with Xenstore. A page allocator can't be that hard to
implement. I wonder if the Xenstore API could be simplified in a way
that does not require threading, thus making the job of implementing
drivers in a min-os a bit simpler?
My feeling is that even a stripped down Linux would take some work to
maintain, at least if we wish to remove the need for hotplug scripts
for driver backends and the like from the miniLinux.
I have little interest in hvm guests, but having a functional mini-os
with an extensible, perhaps oskit- or TinyOS-like, structure would be
a huge win in a number of other situations as well. If I can I would
like to help. If the mini-os ever gets functional, I suppose it would
help to include it in the regression tests, to prevent the bit-rot it
is currently suffering from.
Jacob
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|