[OpenAFS-devel] i386_xenlinux26?

[Troy Benjegerdes]

On Tue, Jun 28, 2005 at 01:50:37PM -0400, Jeffrey Hutzelman wrote:
> 
> 
> On Tuesday, June 28, 2005 12:55:05 AM -0400 Kyle Moffett 
> <mrmacman_g4@mac.com> wrote:
> 
> >On Jun 27, 2005, at 16:39:03, Troy Benjegerdes wrote:
> >>Okay, first of all, the xen people need some polite "education"
> >>because
> >>haveing 'arch/xen' is just a bad idea. What happens if/when xen/
> >>x86_64,
> >>or xen/PPC64, or xen/ia64 show up? PPC and PPC64 do just fine with
> >>with
> >>and without the IBM hypervisor and everything coexists nicely.
> >>
> >>The 'xen' arch is not a new processor, and there is no defensible
> >>reason I can think of to add another sysname.
> >
> >IIRC, at least in terms of the linux source tree, the reasoning behind
> >arch/xen was that it was currently quite ugly.  A number of cleanup
> >patches are in progress, so relatively soon much of this will be merged
> >into the other arch/* trees themselves and the arch/xen directory should
> >go away.  I also see no reason to add a xen sysname.
> 
> Unfortunately, one of the properties of our current build system is that 
> for a different ${ARCH}, you have to have a different sysname.  So our 
> choices basically are to do a "port" with a sysname like i386_xenlinux26 
> (which would be consistent with how we handled UML), or wait for the 
> cleanups of which you speak, and hope the result will be the elimination of 
> arch/xen in favor of a config option.

I think it would be less trouble for everyone in the long run to wait
for the removal of arch/xen. If someone needs to hack up the openafs
build system, maybe put a patch on the openafs web site, or someother
place, but it probably shouldn't be put in the mainline cvs.
 
> It's worth noting that the approach used by Xen requires an architecture 
> with more than two privilege levels, and while i386 and its relatives have 
> that feature, relatively few other architectures do.  So, it may be quite 
> some time before we see a xen for any other architecture.

I'm not so sure.. Even if the Xen/x86 approach requires multiple
priviledges, a virtualization system can work just fine using with the
core virtual machine code running as priviledged, and everything else
running upriviledged, and haveing the VM trap the 'illegal instruction'
handler to emulate priviledged operations. This is what Mac-on-Linux does. 

http://www.maconlinux.org/

There's even a note on the xen-users list about IBM working on a Power5
port. 

http://lists.xensource.com/archives/html/xen-users/2005-05/msg00433.html