| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Pre-OLS attempt for (xen)linux directory structure conve
* Magenheimer, Dan (HP Labs Fort Collins) (dan.magenheimer@xxxxxx) wrote:
> A couple months ago, there was a thread discussing various
> opinions for directory structures for including xenlinux code
> into the Linux tree. (The current structure is not architecture
> independent and also uses some names/terminology that might
> need to change to be more acceptable to Linux kernel
> developers.)
>
> I think Chris Wright said at the time that he would be
> working on a patch to restructure the existing xenlinux
> tree in xenbits, but I don't think this patch has been
> submitted. (Correct, Chris?)
That's correct, no patches yet. Post 2.6.12 merge makes most sense to
start w/ patches to me.
> With OLS (Ottawa Linux Symposium) coming up rapidly, I want
> to resurrect this discussion. If we can converge on
> a solution via email , OLS will be a good forum where we can
> work together to lobby the Linux kernel developers. And if
> we can't converge before OLS, we can have a BOF at the
> mini-summit to see if we (Xen developers) can converge.
>
> I propose that the best chance of success is to look at
> the directory structure strictly from a Linux point-of-view,
> even if it causes some restructuring in the xenbits tree
> and some annoying changes to current include lines.
Agreed.
> Here's a strawman proposal:
Proposal below is essentially same as what came out of summit.
So, from quick look, I certainly agree ;-)
> linux/include/xen/ - contains all xen includes that
> are common (not archdep)
> linux/include/asm-*/xen/ - contains all xen includes
> required for a specific architecture[1]
except s/xen/mach-xen/
> linux/arch/*/xen/ - contains xen code that is archdep
and s/xen/mach-xen/
> linux/drivers/xen/core/ - contains xen code that
> is common to all xen architectures, but is not
> specific to a particular driver class
> linux/drivers/xen/{blkback,...}/ - contains xen code
> that is (or soon will be) common for specific drivers
> CONFIG_XEN is used in config/Makefiles/code.
> CONFIG_XEN_arch (e.g. CONFIG_XEN_X86) is used (only
> if absolutely necessary) in xen common code to
> indicate code that is archdep
>
> [1] this includes header files containing macros/inlines
> to "arch-dep'ify" code in linux/drivers/xen; these
> header files do not exist today because all drivers
> are x86-specific.
>
> Of particular note in this proposal:
> 1) There is NO linux/arch/xen or linux/include/asm-xen. These
> directory names imply that xen is an architecture, whereas
> it actually encompasses several architectures.
> 2) There is NO linux/.../*public/ for xen. The term
> "public" makes sense from Xen's point-of-view but
> is confusing from a Linux point-of-view. Also, the
> files such as public/arch-x86.h would be moved to
> the appropriate include/asm-*/xen directory
Also, since this means those headers are a snapshot, binary compatibility
needs to be (more) carefully considered.
> 3) There is no place to put cross-arch Xen-specific code
> that is not related to drivers. (Is there any?)
> 4) CONFIG_XEN should *not* eliminate the possibility of
> transparent paravirtualization, which works today
> on Linux/ia64.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home