WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] RE: Building domains as a lesser user (was Re: [Xen-deve

To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] RE: Building domains as a lesser user (was Re: [Xen-devel] bootloaders for domain != 0)
From: Mark Williamson <Mark.Williamson@xxxxxxxxxxxx>
Date: Fri, 4 Feb 2005 13:27:33 +0000
Cc: Jeremy Katz <katzj@xxxxxxxxxx>, Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Delivery-date: Fri, 04 Feb 2005 13:36:13 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <1107523253.7797.7.camel@xxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D1236FE@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <1107523253.7797.7.camel@xxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.7.1
> > 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