Re: [Xen-devel] Re: Xen/ia64 presentation

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 27 Apr 2005, at 20:12, Hollis Blanchard wrote:

> > Maintaining close ties to Linux makes it much easier to "go back to
> > the well".  I remember that Xen 1.0 removed a lot of the early
> > "start of day" code for other (e.g. Cyrix) processors; when the
> > user community grew and some users wanted to run on other processors,
> > the Xen team went back and grabbed the code from Linux.
> I don't necessarily see divergence as good or bad, but I don't rule it
> out. The Cyrix thing you described is a fine example of a lazy
> algorithm, which I can see you have lots of respect for. :) Remove
> dubious code, and if it turns out somebody complains (causing a code
> fault ;), it can be re-added. Any code that's kept has to be 
> maintained,
> and if no users even excercise it then it's quite likely to bitrot
> anyways. For example, Linux supports i386 processors as well, but I
> suspect it would be counter-productive to attempt that in Xen.
Exactly: within an architecture I think it makes sense to keep it 
simple but fault in features. I personally fear premature feature-itis 
and flexibility: I'd much rather add things in as they become 
necessary, whatever the project. In the case of Xen, we would otherwise 
forever be a gross hard-to-maintain patch on the side of Linux.
 The other concern that Dan talks about is what the arch-independent 
interface should look like -- I think that this will look really rather 
different between an OS and a hypervisor. For example, an arch with a 
software-managed TLB will not want to cope with generic interfaces 
supporting 3- or 4-level page tables, although that might well make 
sense in an OS (where you need some kind of address-space management 
structure anyway, and might as well look like a pagetable).
 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel