Magenheimer, Dan (HP Labs Fort Collins) wrote:
>
>>In general, why are you so determined to track Linux code? Although
>>Xen/x86 started that way, it has since diverged, and I think
>>that makes
>>a lot of sense. There is likely to be a ton of Linux code supporting
>>features that don't make sense in a hypervisor, right? That has
>>certainly been my experience working on the PowerPC hypervisor over a
>>few years...
>
> It is true that there is a "ton" of Linux code supporting features
> that don't make sense in a hypervisor. But there is a "couple hundred
> pounds of gold/platinum" Linux code that DOES virtually identical things
> to a hypervisor -- at least that is the case for ia64. Unlike
> Linux/x86, much of the core archdep code for Linux/ia64 is still
> changing relatively rapidly (bug fixes and performance improvements).
> When Xen was originally derived from Linux (2.4.7-ish), Linux/ia64
> was very immature. I really had no choice other than to leverage
> a much later version. And there have been many useful changes in
> Linux/ia64 between 2.6.4 (where I started Xen/ia64) and 2.6.11 (which
> is currently being used for Xen/ia64).
Yeah, I can see how rapid evolution is a good reason to try to track
Linux code.
> A friend likes to say that "good programmers are lazy... VERY good
> programmers are VERY lazy". While I can claim only to be lazy (and
> the converse of this aphorism may not be true anyway :-), I hate to
> waste my time writing code that has already been written by someone
> else better than I could have written it anyway. Assembly coding on
> ia64 is very complicated and error prone; code like kernel entry/exit
> on Linux/ia64 is some of the most intricate and cryptic code you may
> ever see. I have the highest level of respect for people like David
> Mosberger who wrote this code but, frankly, I don't want to try to
> maintain a parallel version of it.
It is a bit scary that IA64 assembly is so difficult that HP Research
doesn't want to touch it with a 10-foot pole. ;)
Actually I'm a bit surprised that you can reuse Linux assembly so
easily. Exception vectors are exactly one of the places I would expect
hypervisor code to differ the most from OS code.
> IBM's pHype and vHype were written as closed source (and pHype still
> is).
> Xen and Xen/ia64 were written with open source and GPL in mind and
> so there was no problem with leveraging Linux code directly. I'd
> venture to guess that 40%-60% of the code in Xen/x86 is directly
> taken or indirectly derived (e.g. minor syntactic changes) from Linux.
> Ian argues that, although this might be true, the other 40-60% is
> the core value of Xen. Which exactly supports my point: why should
> the Xen team waste time on developing/changing the "non-core" part of
> Xen when it can be directly leveraged from Linux?
But at what cost? It is not direct leverage -- you need look no further
than xen/arch/ia64/patch/ for evidence of that. And even with the
patching, the result is inconsistent at best; for example, "struct
pt_regs" used in Linux code and "struct xen_regs" used in native Xen
code. That really hurts readability and maintainability. And unless you
run through the IA64 patch process, tools like cscope won't even see all
that Linux code.
> It's true that Xen is slowly diverging from the original Linux code.
> You see this as a good thing. I disagree. There are few good examples
> of highly portable systems code, but Linux is one of them. Many
> things look "a little weird" in Linux because the code supports
> multiple architectures. A good example is allocating a task struct
> (see below). I'd argue that one of the key factors for Linux's current
> and future success is its ubiquity due its portability; and Xen would
> do well to follow in its footsteps rather than diverge in ways that
> will very likely make it less portable.
I'm all about the portability, but it may turn out that the architecture
API is drawn at a different level in a hypervisor than in an OS. I think
that's something we should see for ourselves, rather than copying Linux
verbatim.
Don't get me wrong; I definitely think Linux is an excellent model for
portable systems code. But it is just that -- a model.
> 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.
> When the
> ACPI tables needed to be more fully parsed, the Xen team grabbed
> the ACPI code from Linux. Recently, when I needed to add "user access"
> capability to Xen/ia64, I grabbed the exception table code from
> Linux/ia64 (and Linux common code); it basically just worked, in part
> because Keir had grabbed the x86 equivalent code earlier.
>
> And I expect this trend to continue and not slow down. For example,
> when I start SMP support, all the important places are marked in
> Linux code by CONFIG_SMP. When I want to implement hot plug memory/CPUs
> or NUMA or jiffieless timer support, I'll know where to look.
Oh absolutely, but I think you're doing a lot more than just looking.
When I want to know how something works, Linux code is at the top of my
reading list, but having looked I can then implement it myself. Being
able to copy/paste/modify isn't a requirement IMHO.
> Some may argue that this is all a good reason to put Xen and Linux
> in the same source tree. I'm not sure I would go that far. But,
> please, let's not kill the golden goose for what amounts to a little
> convenience and aesthetics.
Maybe it's just me, but I find the Xen/ia64 code confusing enough that I
wouldn't call it just a little aesthetics... :)
>>Unrelated to the presentation, I've noticed a large amount of
>>commented-out code and definitions in Xen/ia64 code, and
>>other oddities
>>like "typedef struct exec_domain VCPU". Are these artifacts of
>>borrowing code from other sources? Are you planning on doing some
>>cleanup in the future?
>
> Yeah, there are some artifacts and some cleanup would be good.
> The typedef predates exec_domain (used to be a typedef of
> struct domain) and I used it because I knew that exec_domain
> was coming. Personally, I prefer VCPU (virtual CPU) to exec_domain.
I've had the same thought actually... an "exec_domain" is really a
virtual CPU state, and having a separate vcpu_info_t is rather confusing.
However, I don't think it helps things to go renaming core structures in
arch code because it sounds better... :)
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home