RE: arch/xen is a bad idea

[Ian Pratt]

 > > I think there's an interim compromise position that 
> everyone might go
> > for:
> > 
> > Phase 1 is for us to submit a load of patches that squeeze 
> out the low
> > hanging fruit in unifying xen/i386 and i386. Most of these will be
> > strict cleanups to i386, and the result will be to almost halve the
> > number of files that we need to modify.
> 
> OK.  It would be good to have a phase 0: any refactoring, 
> abstracting, etc
> to the core kernel and to i386 which is a preparatory step, prior to
> introducing any Xen code.  After phase 0 everything should 
> still compile
> and run.  The subsequent Xen patches should merely add stuff 
> and not move
> existing code around.

I think my phase 1 and your phase 0 are actually the same. I'm not
proposing that we put any Xen code in the tree at this point, but that
we do the many easy cleanups to i386 which will mean that we can remove
modifications to files from the arch/xen tree we maintain .

Example cleanups would be: use a macro for testing to see whether you're
in the kernel or not; use isa_bus_to_virt instead of phys_to_virt for
the access the address of the VGA console etc etc.

> What would you propose doing with the i386 header files?  Such as the
> pagetable handling?

We'd certainly still need to have xen-specific versions of some of the
i386 header files. Perhaps the neatest thing is to have an
include/asm-i386/xen ahead of include/asm-i386 on the include search
path?  Not sure.


Ian 
-
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/