Re: [Xen-devel] RE: Building domains as a lesser user (was Re: [Xen-devel] bootloaders for domain != 0)

[Mark Williamson <Mark.Williamson@xxxxxxxxxxxx>]

> > I don't see why the filesystems would particularly need to be modular,
> > though you might do so for convenience.
>
> Because if the kernel is _different_ than every other kernel being
> shipped by a distribution, then it's a major pain.  It also ends up
> giving people a lot less flexibility (because if I were to do that, for
> example, it would only have ext[23] support leaving users of
> reiserfs/xfs/jfs/foofs out in the cold whereas with a modular solution,
> they can at least add the support for what they want).

Well we'll have to have a special initrd to run the "bootloader" program from 
anyhow, so I guess incorporating whatever filesystems the default distro 
kernel has as modules on there won't be particularly arduous.

> > > And then, it's yet another kernel to keep updated, etc.
> >
> > I don't see any reason to keep it up to date. Its running in a protected
> > environemnt and doesn't have any extra access that the kernel about to
> > be booted is going to get.
>
> Users don't tend to take that answer very well ;)  The protected
> environment means you can have a little bit longer to fix it, but they
> have things like audit requirements, etc.

OK but the kernel can be essentially airgapped from the rest of the world - 
not necessary to include network drivers, etc (or if we do, not strictly 
necessary to connect the device channels).  Security shouldn't be the issue, 
so if it works I wouldn't think it'd need updating regularly.

To be honest, I think whatever solution we go with is going to look a little 
messy.

Cheers,
Mark


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel