Re: arch/xen is a bad idea
From: Antonio Vargas
Date: Tue Dec 14 2004 - 14:42:02 EST
On 14 Dec 2004 19:59:50 +0100, Andi Kleen <ak@xxxxxxx> wrote:
> "Andi Kleen" <ak@xxxxxxx> writes:
> [again this time with subject. sorry for the screwup]
> [very late answer]
> > Stunned silence I guess - merging an architecture is
> > usually much more controversial ;)
> In my opinion it's still an extremly bad idea to have arch/xen
> an own architecture. It will cause a lot of work long term
> to maintain it, especially when it gets x86-64 support too.
> It would be much better to just merge it with i386/x86-64.
> Currently it's already difficult enough to get people to
> add fixes to both i386 and x86-64, adding fixes to three
> or rather four (xen32 and xen64) architectures will be quite bad.
> In practice we'll likely get much worse code drift and missing
> fixes. Also I still suspect Ian is underestimating how much
> work it is long term to keep an Linux architecture uptodate.
> I cannot imagine the virtualization hooks are intrusive anyways. The
> only things it needs to hook idle and the page table updates, right?
> Doing that cleanly in the existing architectures shouldn't be that
> I suspect xen64 will be rather different from xen32 anyways
> because as far as I can see the tricks Xen32 uses to be
> fast (segment limits) just plain don't work on 64bit
> because the segments don't extend into 64bit space.
> So having both in one architecture may also end up messy.
> And i386 and x86-64 are in many pieces very different anyways,
> I have my doubts that trying to mesh them together in arch/xen
> will be very pretty.
> Also the other thing I'm worried about is that there is no clear
> specification on how the Xen<->Linux interface works. Assuming
> there will be other para Hypervisors in the future too will we
> end up with even more virtual architectures? It would be much
> better to have at least a somewhat defined "linux virtual interface"
> first that is actually understood by multiple people outside
> the Xen group.
> I think before merging stuff the hypervisor interfaces need to be
> discussed on linux-kernel. Splitting the patches and posting them
> as individual pieces for i386 with good description will be a good
> first step for that.
Andi, there is at least one other hypervisor interface, mac-on-linux
features a kernel module that allows booting other kernels inside the
running one, and keeps very good speed anyways.
Their code, at least the user-space part, was also very good coded
for my eyes.
Driver support is done by exporting a customized open-firmware
device tree and then implementing drivers for these devices on
the client OSs.
(just goto http://www.maconlinux.org/ and have a look)
Oh, this is obviusly ppc-only ATM :)
Greetz, Antonio Vargas aka winden of network
Las cosas no son lo que parecen, excepto cuando parecen lo que si son.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/