> > 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
|