[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Pre-OLS attempt for (xen)linux directory structure convergence


  • To: "Chris Wright" <chrisw@xxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Mon, 4 Jul 2005 19:20:31 -0700
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 05 Jul 2005 02:19:15 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcWBBqR+PkTLXPOQSpeTEg6DrXQkeQAAGmhA
  • Thread-topic: [Xen-devel] Pre-OLS attempt for (xen)linux directory structure convergence

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

Doesn't mach-xen imply (to a Linux kernel developer) that
xen is disjoint with and cannot co-exist with the other
mach-*?  Whereas leaving off the mach- implies that xen
more of a configurable option that may apply to multiple
mach- types?  (Or perhaps I am just thinking of "machvec"
on ia64?)

I guess I don't care whether there is a mach- prefix or
not but want to ensure Linux conventions are kept where
possible.
 
> Also, since this means those headers are a snapshot, binary 
> compatibility
> needs to be (more) carefully considered.

Good point.  Perhaps we should specify VERSION macros like
Linux has (for both Linux and gcc)?

Dan

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.