RE: [Xen-merge] xen-merge mailing list

["Martin J. Bligh" <mbligh@xxxxxxxxxx>]

> I'm not sure if there is a VMI patch against x86_64 at this point, but
> I'm cleaning up the x86_64 code so that we can share the code with the
> native Linux cleanly. 

That sounds like an excellent plan, poking around it seems like the 
division between x86 and x86_64 isn't particularly clean - seems to be 
a lot of copied code (not Xen stuff, but just pre-existant).

> At this point, I'm using #ifdef CONFIG_XEN as agreed with Andi.
>
>> Also, Andi mentioned to me that he'd actually prefer to try and merge
>> the x86_64 bits directly into the x86_64 port rather than add a
>> sub-arch there if possible (Andi, please correct me if I
>> misunderstood). 

Seems odd that Andi would suggest such a thing ... flies directly in 
the face of what most people are recommending to do with Linux code, 
particularly if it's mid-function. Personally I think subarches do
clean up the code a lot, if they're done sensibly, and we're going
to have to cope with things like summit subarch in x86_64 as well.
I fought against doing it for ia32 at first ... then realized I was
wrong. If we just want to throw some files in subdirs instead of a
"subarch", is good ... but you end up with pretty much the same thing.

Andi, you objected to subarches when we talked at OLS ... what exactly
was the issue, and is it fixable? Not sure it's any worse than the
alternatives, at any rate.

Even if one did not one a subarch, it makes the code much cleaner and 
easier to read to define macros at suitable abstraction points, even if 
it's just

static inline wibble_with_foo (int bar, int blat) {
#ifdef CONFIG_XEN
        do A
#else
        do B
#endif.
}

which gets stuck in a header file somewhere. Then we just have
"wibble_with_foo(bar, blat);" in the main code, which makes it much
easier to read (assuming you picked a meaningful function name).
Perhaps I'm just reading too much into your "ifdefs" thing, and this
is more what you're intending.

M.

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