This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] tidy up requested

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] tidy up requested
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Wed, 10 Aug 2005 23:21:49 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Delivery-date: Wed, 10 Aug 2005 22:22:59 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <E1E2tgW-0006vl-00@xxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <E1E2tgW-0006vl-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8.2
> install > find . -type f | grep -v /lib/modules | grep -v /boot
> ./usr/lib/libxc.so.3.0.0
> ./usr/lib/libxc.a
> ./usr/lib/libxenstore.a
> ./usr/lib/libxenstore-pic.a
> I guess the above are OK.  Makes me wander whether we should
> rename libxc to libxenc ???

libxc seems fine to me but libxenc is more obviously Xen related.  If we 
change it I'd vote for changing to "libxenctl" whilst we have the chance.

> ./usr/include/xc.h
> ./usr/include/xs.h
> ./usr/include/xs_lib.h
> ./usr/include/xcs_proto.h
> Should the above be under a /usr/include/xen too?


> ./usr/sbin/xenstored                  <-- move to /usr/lib/xen/sbin
> ./usr/sbin/netfix                     <-- delete

> ./usr/sbin/xm                         <-- move to /usr/bin
Nah, I think we should keep user-accessible control tools under /usr/sbin.

> ./usr/sbin/xend
> ./usr/sbin/xenperf                    <-- move to /usr/lib/xen/bin


> ./usr/sbin/xcs                                (about to be deleted)
> ./usr/sbin/xcsdump                    <-- move to /usr/lib/xen/bin
> ./usr/sbin/xenconsoled                        <-- move to /usr/lib/xen/sbin

Hang on - do we have a clear standard for /usr/lib/xen/{bin,sbin}?  Generally 
I agree with your division (although we should surely kill xcsdump if we kill 
xcs - the new tools won't really have an equivalent, other than directory 
browsing of the store).

> ./usr/share/xen/qemu/keymaps/da
> ./usr/share/xen/qemu/keymaps/en-gb
> ...
> ./usr/share/xen/qemu/keymaps/pt
> ./usr/share/xen/qemu/keymaps/sl
> ./usr/share/xen/qemu/keymaps/tr
> Should the above really go in /usr/share ???

*shrug* they're not really shared data...  How about *either* putting them 
in /usr/lib/xen/, or using the standard QEmu locations?

> ./usr/bin/xenperf                     <-- duplicate of /usr/sbin/xenperf?
Doesn't sound like we need both...
> ./usr/bin/xc_shadow                   <-- move to /usr/lib/xen/bin
> ./usr/bin/xencons                     <-- redundant?
Possibly, although it still might be useful for TCP-exported consoles.
> ./usr/bin/cpuperf-xen                 <-- move to /usr/lib/xen/bin
> ./usr/bin/cpuperf-perfcntr<-- should not be installed
> ./usr/bin/lomount                     (useful)
Maybe this should be /usr/sbin?  I guess we should go wherever the default for 
lomount is, in this instance.
> ./usr/bin/xentrace                    <-- move to /usr/lib/xen/bin
> ./usr/bin/xentrace_format             <-- move to /usr/lib/xen/bin
Hmmm...  they're intended for direct invocation so I'd tend towards some other 
location.  Maybe /usr/sbin/ - they probably shouldn't be in /usr/bin.
> ./usr/libexec/xen/xc_restore
> ./usr/libexec/xen/xc_save
> ./usr/libexec/xen/xenconsole
Bzzzt!  I thought libexec was deprecated?  /usr/lib/xen/sbin?
> ./etc/init.d/xend
> ./etc/init.d/xendomains                       (needs review)
We should have xendomains equivalent functionality *somewhere* - whether in a 
daemon or in the init scripts doesn't really matter.
> ./etc/xen/xend-config.sxp
> ./etc/xen/xmexample1
> ./etc/xen/xmexample2
> ./etc/xen/xmexample.vmx
> ./etc/xen/scripts/network             <- rename to network-bridge
> ./etc/xen/scripts/vif-bridge
> ./etc/xen/scripts/network-route
> ./etc/xen/scripts/vif-route
> ./etc/xen/scripts/block-file
> ./etc/xen/scripts/block-enbd
> ./etc/xen/qemu-ifup                   <- move to /etc/xen/scripts/
> ./etc/xen/qemu-vgaram-bin             <- move to /usr/lib/xen/boot
> ./usr/lib/xen/bin/qemu-dm
> ./usr/lib/xen/bin/qemu-dm.debug
/usr/lib/xen/sbin perhaps?  They're not normal user comands (particularly not 
the device model daemon!).
> ./usr/lib/python/xen/__init__.py
> ./usr/lib/python/xen/lowlevel/__init__.py
> ./usr/lib/python/xen/lowlevel/xc.so
> ./usr/lib/python/xen/lowlevel/xu.so
> ...
> ./usr/lib/python/xen/sv/Wizard.pyc
> ./usr/lib/python/xen/sv/__init__.pyc
> ./usr/lib/python/xen/sv/util.pyc
> ./usr/lib/python/xen/__init__.pyc
Seem reasonable to me...
> ./usr/share/doc/xen/ps/interface.ps
> ./usr/share/doc/xen/ps/user.ps
> ./usr/share/doc/xen/pdf/interface.pdf
> ./usr/share/doc/xen/pdf/user.pdf
> ./usr/share/doc/xen/html/interface/index.html
> ./usr/share/doc/xen/html/interface/WARNINGS
> ./usr/share/doc/xen/html/interface/interface.html
Seem reasonable also.

> ./usr/share/doc/xen/html/user/labels.pl
> ./usr/share/doc/xen/html/user/images.pl
Don't know what these do - who uses them?
> ./usr/share/doc/xen/html/user/user.css
> ./usr/share/man/man1/xentrace_format.1
> ./usr/share/man/man8/xentrace.8
> more man pages would be good... :-)
Yes, but only if we can keep them reliably up to date in the release code!  
Either we should get some docs guidelines which we enforce when accepting 
patches, or we should gather all the docs in one place, e.g. using Texinfo 
(yes, yes, many of you probably hate it) and make that the definitive source.


Xen-devel mailing list