Re: [Xen-devel] tidy up requested

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

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

Yes!

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

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

Yep.

> ./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
Yep.
> ./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
OK...
> ./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
OK.
> ./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
Fine.
> ./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
Yup.
> ./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.

Cheers,
Mark

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