tidy up requested

tidy up requested

[Ian Pratt]

I've just looked at the set of files we install. It's a mess, and
we need to tidy it up. What to people think about the following?
Volunteers?

Thanks,
Ian



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

./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/include/xen/io/blkif.h
./usr/include/xen/io/domain_controller.h
./usr/include/xen/io/ioreq.h
./usr/include/xen/io/netif.h
./usr/include/xen/io/ring.h
./usr/include/xen/io/usbif.h
./usr/include/xen/io/vmx_vlapic.h
./usr/include/xen/acm.h
./usr/include/xen/acm_ops.h
./usr/include/xen/arch-ia64.h
./usr/include/xen/arch-x86_32.h
./usr/include/xen/arch-x86_64.h
./usr/include/xen/dom0_ops.h
./usr/include/xen/event_channel.h
./usr/include/xen/grant_table.h
./usr/include/xen/physdev.h
./usr/include/xen/sched_ctl.h
./usr/include/xen/trace.h
./usr/include/xen/version.h
./usr/include/xen/vmx_assist.h
./usr/include/xen/xen.h
./usr/include/xen/COPYING
./usr/include/xen/linux/privcmd.h
./usr/include/xen/linux/suspend.h


./usr/sbin/xenstored			<-- move to /usr/lib/xen/sbin	
./usr/sbin/netfix			<-- delete
./usr/sbin/xm				<-- move to /usr/bin
./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	


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


./usr/bin/xenperf			<-- duplicate of /usr/sbin/xenperf?
./usr/bin/xc_shadow			<-- move to /usr/lib/xen/bin
./usr/bin/xencons			<-- redundant?
./usr/bin/cpuperf-xen			<-- move to /usr/lib/xen/bin
./usr/bin/cpuperf-perfcntr<-- should not be installed
./usr/bin/lomount			(useful)
./usr/bin/xentrace			<-- move to /usr/lib/xen/bin
./usr/bin/xentrace_format		<-- move to /usr/lib/xen/bin
./usr/libexec/xen/xc_restore
./usr/libexec/xen/xc_save
./usr/libexec/xen/xenconsole
./etc/init.d/xend
./etc/init.d/xendomains			(needs review)
./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/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



./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
...
./usr/share/doc/xen/html/user/labels.pl
./usr/share/doc/xen/html/user/images.pl
./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... :-)

Re: tidy up requested

[Ronald G Minnich]

One thing I'd really like would be a setup where multiple xen versions 
could co-exist on one platform. If you were to put the xen path into the 
names you select, that would really help me a lot. I can't really use 
3.0 yet, I do work under 2.0, but I can not develop on 3.0 and use 2.0 
on the same box. Any chance of getting this fixed? I know this has come 
up before, but hey, you asked for input :-)

ron

Re: tidy up requested

[Sean Dague]

[-- Attachment #1.1: Type: text/plain, Size: 4996 bytes --]

On Wed, Aug 10, 2005 at 05:44:08PM +0100, Ian Pratt wrote:
> 
> I've just looked at the set of files we install. It's a mess, and
> we need to tidy it up. What to people think about the following?
> Volunteers?
> 
> Thanks,
> Ian
> 
> 
> 
> 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 ???
> 
> ./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/include/xen/io/blkif.h
> ./usr/include/xen/io/domain_controller.h
> ./usr/include/xen/io/ioreq.h
> ./usr/include/xen/io/netif.h
> ./usr/include/xen/io/ring.h
> ./usr/include/xen/io/usbif.h
> ./usr/include/xen/io/vmx_vlapic.h
> ./usr/include/xen/acm.h
> ./usr/include/xen/acm_ops.h
> ./usr/include/xen/arch-ia64.h
> ./usr/include/xen/arch-x86_32.h
> ./usr/include/xen/arch-x86_64.h
> ./usr/include/xen/dom0_ops.h
> ./usr/include/xen/event_channel.h
> ./usr/include/xen/grant_table.h
> ./usr/include/xen/physdev.h
> ./usr/include/xen/sched_ctl.h
> ./usr/include/xen/trace.h
> ./usr/include/xen/version.h
> ./usr/include/xen/vmx_assist.h
> ./usr/include/xen/xen.h
> ./usr/include/xen/COPYING
> ./usr/include/xen/linux/privcmd.h
> ./usr/include/xen/linux/suspend.h
> 
> 
> ./usr/sbin/xenstored			<-- move to /usr/lib/xen/sbin	
> ./usr/sbin/netfix			<-- delete
> ./usr/sbin/xm				<-- move to /usr/bin
xm is an administrative command, sbin is probably a good place to keep it.

> ./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	
> 
> 
> ./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 ???
> 
> 
> ./usr/bin/xenperf			<-- duplicate of /usr/sbin/xenperf?
> ./usr/bin/xc_shadow			<-- move to /usr/lib/xen/bin
> ./usr/bin/xencons			<-- redundant?
> ./usr/bin/cpuperf-xen			<-- move to /usr/lib/xen/bin
> ./usr/bin/cpuperf-perfcntr<-- should not be installed
> ./usr/bin/lomount			(useful)
> ./usr/bin/xentrace			<-- move to /usr/lib/xen/bin
> ./usr/bin/xentrace_format		<-- move to /usr/lib/xen/bin
> ./usr/libexec/xen/xc_restore
> ./usr/libexec/xen/xc_save
> ./usr/libexec/xen/xenconsole
> ./etc/init.d/xend
> ./etc/init.d/xendomains			(needs review)
> ./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

It would also be nice if the installer didn't clobber files in /etc, having
to remember to fix /etc/xen/xend-config.sxp after every install gets tiring.

> ./usr/lib/xen/bin/qemu-dm
> ./usr/lib/xen/bin/qemu-dm.debug
> 
> 
> ./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
> 
> 
> 
> ./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
> ...
> ./usr/share/doc/xen/html/user/labels.pl
> ./usr/share/doc/xen/html/user/images.pl
> ./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... :-)

I had a patch that added one for xendomain.cfg.5 (the xm create config
files) and xm.1 (though pretty empty).  I spent a little more time on it
this morning, and can resend the patch if you like.

	-Sean

-- 
__________________________________________________________________

Sean Dague                                       Mid-Hudson Valley
sean at dague dot net                            Linux Users Group
http://dague.net                                 http://mhvlug.org

There is no silver bullet.  Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: tidy up requested

[Nivedita Singhvi]

Ian Pratt wrote:


> ./etc/xen/scripts/network		<- rename to network-bridge

This one, at least, had posted a patch for before, but if you're
checking in the new network script, it will be obsolete already,
so why not kill 2 birds with one stone and rename and check-in,
and blow the old one?

thanks,
Nivedita

Re: tidy up requested

[Mark Williamson]

> 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

Re: tidy up requested

[Ronald G Minnich]

So I can not convince you to allow multiple versions of xen on one machine?

People who are using 2.0 and porting to 3.0 (like me and newsham and 
...) could sure use that setup!

ron

Re: tidy up requested

[Andi Kleen]

Ronald G Minnich <rminnich@lanl.gov> writes:

> So I can not convince you to allow multiple versions of xen on one machine?
> 
> People who are using 2.0 and porting to 3.0 (like me and newsham and
> ...) could sure use that setup!

The standard way to do that would be to support $(prefix) properly.
So you end up with $(prefix)/lib/xen ..  $(prefix)/sbin $(prefix)/etc ...
Like /opt/xen2/.... /opt/xen3/... etc.

The problem would be to make sure that all tools that read files
or execute programs know about the prefix.

-Andi

Re: tidy up requested

[Anthony Liguori]

Mark Williamson wrote:

>>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.
>  
>
Let me cast my vote for libxencontrol then.

>>./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!
>  
>
Perhaps now is an appropriate time to introduce two other things, a 
PREFIX variable settable in the top-level Makefile and a pkg-config 
scripts for xcs and the xenstore.  Thoughts?

I'll volunteer to take a pass at cleanup.  I'll make a first pass 
tomorrow (leaving out the prefix/pkg-config stuff until there's more 
discussion).

Regards,

Anthony Liguori

>Cheers,
>Mark
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>  
>

Re: Re: tidy up requested

[Anthony Liguori]

Andi Kleen wrote:

>Ronald G Minnich <rminnich@lanl.gov> writes:
>
>  
>
>>So I can not convince you to allow multiple versions of xen on one machine?
>>
>>People who are using 2.0 and porting to 3.0 (like me and newsham and
>>...) could sure use that setup!
>>    
>>
>
>The standard way to do that would be to support $(prefix) properly.
>So you end up with $(prefix)/lib/xen ..  $(prefix)/sbin $(prefix)/etc ...
>Like /opt/xen2/.... /opt/xen3/... etc.
>
>The problem would be to make sure that all tools that read files
>or execute programs know about the prefix.
>  
>
Yeah, I've got a pretty good feel for what needs to change.  Not 
surprisingly, Xend will be the most pain here.  I think we can actually 
be smart though and avoid having to know the prefix at compile time.

Regards,

Anthony Liguori

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

Re: tidy up requested

[Mark Williamson]

> So I can not convince you to allow multiple versions of xen on one machine?
>
> People who are using 2.0 and porting to 3.0 (like me and newsham and
> ...) could sure use that setup!

Personally I think it'd be nice to have - I'm with you on that.  I'm not sure 
it's critical right now *but* it's worth considering for the long term for 
users testing future versions of Xen - even though 3.0 will (obviously ;-) be 
great and make everyone want to upgrade, it's going to get annoying for IT 
folks who really do want to test multiple versions.

Cheers,
Mark

Re: tidy up requested

[Arun Sharma]

Ian Pratt wrote:

> ./etc/xen/qemu-ifup			<- move to /etc/xen/scripts/

ok.

> ./etc/xen/qemu-vgaram-bin		<- move to /usr/lib/xen/boot

Will delete this one. We always go through the vmxloader now.

	-Arun

Re: tidy up requested

[Rusty Russell]

On Wed, 2005-08-10 at 17:44 +0100, Ian Pratt wrote:
> ./usr/sbin/xcsdump			<-- move to /usr/lib/xen/bin
> ./usr/sbin/xenconsoled			<-- move to /usr/lib/xen/sbin	

I would recommend folding /usr/lib/xen/sbin into /usr/lib/xen/bin; since
neither is going to be in anyone's path, having them split seems silly.

> ./usr/libexec/xen/xc_restore
> ./usr/libexec/xen/xc_save
> ./usr/libexec/xen/xenconsole

/usr/lib/xen/bin too I think.  /usr/libexec never really caught on.

Cheers,
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

RE: tidy up requested

[Ian Pratt]

> On Wed, 2005-08-10 at 17:44 +0100, Ian Pratt wrote:
> > ./usr/sbin/xcsdump			<-- move to /usr/lib/xen/bin
> > ./usr/sbin/xenconsoled			<-- move to 
> /usr/lib/xen/sbin	
> 
> I would recommend folding /usr/lib/xen/sbin into 
> /usr/lib/xen/bin; since neither is going to be in anyone's 
> path, having them split seems silly.

I agree.
 
> > ./usr/libexec/xen/xc_restore
> > ./usr/libexec/xen/xc_save
> > ./usr/libexec/xen/xenconsole
> 
> /usr/lib/xen/bin too I think.  /usr/libexec never really caught on.

Yep -- missed these in my original message.

How's the attached?
Ian


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

Rename libxc to libxenctl

./usr/include/xc.h
./usr/include/xs.h
./usr/include/xs_lib.h
./usr/include/xcs_proto.h

Move the above to /usr/include/xen

./usr/include/xen/io/blkif.h
./usr/include/xen/io/domain_controller.h
./usr/include/xen/io/ioreq.h
./usr/include/xen/io/netif.h
./usr/include/xen/io/ring.h
./usr/include/xen/io/usbif.h
./usr/include/xen/io/vmx_vlapic.h
./usr/include/xen/acm.h
./usr/include/xen/acm_ops.h
./usr/include/xen/arch-ia64.h
./usr/include/xen/arch-x86_32.h
./usr/include/xen/arch-x86_64.h
./usr/include/xen/dom0_ops.h
./usr/include/xen/event_channel.h
./usr/include/xen/grant_table.h
./usr/include/xen/physdev.h
./usr/include/xen/sched_ctl.h
./usr/include/xen/trace.h
./usr/include/xen/version.h
./usr/include/xen/vmx_assist.h
./usr/include/xen/xen.h
./usr/include/xen/COPYING
./usr/include/xen/linux/privcmd.h
./usr/include/xen/linux/suspend.h


./usr/sbin/xenstored			<-- move to /usr/lib/xen/bin	
./usr/sbin/netfix				<-- delete
./usr/sbin/xm				
./usr/sbin/xend				
./usr/sbin/xenperf			<-- move to /usr/lib/xen/bin	
./usr/sbin/xcs				(about to be deleted)
./usr/sbin/xcsdump			(delete)
./usr/sbin/xenconsoled			<-- move to /usr/lib/xen/bin	


./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
/usr/lib/xen/qemu ???

./usr/bin/xenperf				<-- duplicate of
/usr/sbin/xenperf?
./usr/bin/xc_shadow			<-- move to /usr/lib/xen/bin
./usr/bin/xencons				<-- redundant?
./usr/bin/cpuperf-xen			<-- move to /usr/lib/xen/bin
./usr/bin/cpuperf-perfcntr		<-- should not be installed
./usr/bin/lomount				<-- move to /usr/sbin
./usr/bin/xentrace			<-- move to /usr/lib/xen/bin
./usr/bin/xentrace_format		<-- move to /usr/lib/xen/bin
./usr/libexec/xen/xc_restore		<-- move to /usr/lib/xen/bin
./usr/libexec/xen/xc_save		<-- move to /usr/lib/xen/bin
./usr/libexec/xen/xenconsole		<-- move to /usr/lib/xen/bin
./etc/init.d/xend
./etc/init.d/xendomains			(needs review)
./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		<- delete?

./usr/lib/xen/bin/qemu-dm
./usr/lib/xen/bin/qemu-dm.debug


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

Re: tidy up requested

[Jacob Gorm Hansen]

Anthony Liguori wrote:

> Perhaps now is an appropriate time to introduce two other things, a
> PREFIX variable settable in the top-level Makefile and a pkg-config
> scripts for xcs and the xenstore.  Thoughts?

Would that mean I would have to have the xen headers and libs installed
(like in recent autoconf-using vmtools) to be able to compile these?  I
just spent the afternoon yesterday editing all the autoconf-cr*p out of
vmtools, because I prefer to be able to compile everything from the xen
tree without having to do a make install of xen first.

If this is the case, please don't. I have Jamfiles for most of the core
tools and vmtools for anyone who is interested. They support fast and
clean builds to a separate build-directory (without fear of
name-collisions), and they allow me to have as many xen-checkouts on my
build machine as I want, without being root, without a separate
configure step and resulting mess of autogenerated .h files, and without
any 'make installs'.

Best regards,
Jacob

Re: tidy up requested

[Sean Dague]

[-- Attachment #1.1: Type: text/plain, Size: 1752 bytes --]

On Thu, Aug 11, 2005 at 01:36:21PM +0200, Jacob Gorm Hansen wrote:
> Anthony Liguori wrote:
> 
> > Perhaps now is an appropriate time to introduce two other things, a
> > PREFIX variable settable in the top-level Makefile and a pkg-config
> > scripts for xcs and the xenstore.  Thoughts?
> 
> Would that mean I would have to have the xen headers and libs installed
> (like in recent autoconf-using vmtools) to be able to compile these?  I
> just spent the afternoon yesterday editing all the autoconf-cr*p out of
> vmtools, because I prefer to be able to compile everything from the xen
> tree without having to do a make install of xen first.

:vm-tools> ./configure --with-xen-source=../wherever/you/like

No need for root, no need to install xen first.

> If this is the case, please don't. I have Jamfiles for most of the core
> tools and vmtools for anyone who is interested. They support fast and
> clean builds to a separate build-directory (without fear of
> name-collisions), and they allow me to have as many xen-checkouts on my
> build machine as I want, without being root, without a separate
> configure step and resulting mess of autogenerated .h files, and without
> any 'make installs'.
> 
> Best regards,
> Jacob

	-Sean

-- 
__________________________________________________________________

Sean Dague                                       Mid-Hudson Valley
sean at dague dot net                            Linux Users Group
http://dague.net                                 http://mhvlug.org

There is no silver bullet.  Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Re: tidy up requested

[Jacob Gorm Hansen]

Sean Dague wrote:
> 
> :vm-tools> ./configure --with-xen-source=../wherever/you/like
> 
> No need for root, no need to install xen first.

Didn't work for me when I tried, plus I would like to avoid the (slow,
messy) configure step if I can. I can't complain (though I did) if the
authors of vm-tools feel the need to use autoconf, but I would be
against it spreading to the rest of the xen tools.

Btw, Freshmeat has an editorial about the problems with make and
make-derived tools, at http://freshmeat.net/articles/view/1702/

Jacob

Re: tidy up requested

[Jacob Gorm Hansen]

Sean Dague wrote:
> On Thu, Aug 11, 2005 at 01:36:21PM +0200, Jacob Gorm Hansen wrote:
> 
>>Anthony Liguori wrote:
>>
>>
>>>Perhaps now is an appropriate time to introduce two other things, a
>>>PREFIX variable settable in the top-level Makefile and a pkg-config
>>>scripts for xcs and the xenstore.  Thoughts?
>>
>>Would that mean I would have to have the xen headers and libs installed
>>(like in recent autoconf-using vmtools) to be able to compile these?  I
>>just spent the afternoon yesterday editing all the autoconf-cr*p out of
>>vmtools, because I prefer to be able to compile everything from the xen
>>tree without having to do a make install of xen first.

Oh, and I forgot to say that recent vm-tools totally rule btw :-) The
later releases appear to be rock-solid.

Jacob

Re: Re: tidy up requested

[Daniel Hulme]

[-- Attachment #1.1: Type: text/plain, Size: 1238 bytes --]

> >>So I can not convince you to allow multiple versions of xen on one
> >>machine?
> >>People who are using 2.0 and porting to 3.0 (like me and newsham and
> >>...) could sure use that setup!

> Yeah, I've got a pretty good feel for what needs to change.  Not 
> surprisingly, Xend will be the most pain here.  I think we can
> actually  be smart though and avoid having to know the prefix at
> compile time.

Actually, while you're at it, could we make Xen aware of LOCALVERSION,
so you can 'make LOCALVERSION=_foo dist', and not only would you get
custom kernels that can co-exist with other kernels (as already
happens), but you also get xen-3.0-devel_foo.gz that can be installed
nicely without overwriting other Xen builds you have. That would have
made things much easier for me this week, and I suspect it would
continue to do so.

I suggest this would be additional to, and not replace, support for
$prefix.

-- 
Stop the infinite loop, I want to get off!     http://surreal.istic.org/
Paraphernalia/Never hides your broken bones,/ And I don't know why you'd
want to try:/ It's plain to see you're on your own.        -- Paul Simon
  The documentation that can be written is not the true documentation.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: tidy up requested

[Jacob Gorm Hansen]

Sean Dague wrote:

> :vm-tools> ./configure --with-xen-source=../wherever/you/like
> 
> No need for root, no need to install xen first.

It fails when looking for libxc with:

"configure: error: libxc doesn't appear to be installed. please install
xen and try again"

I guess that makes sense when dynamically linking libxc, normally I just
use static linking.

Jacob

Re: Re: tidy up requested

[Rusty Russell]

On Thu, 2005-08-11 at 14:38 +0200, Jacob Gorm Hansen wrote:
> Sean Dague wrote:
> > 
> > :vm-tools> ./configure --with-xen-source=../wherever/you/like
> > 
> > No need for root, no need to install xen first.
> 
> Didn't work for me when I tried, plus I would like to avoid the (slow,
> messy) configure step if I can. I can't complain (though I did) if the
> authors of vm-tools feel the need to use autoconf, but I would be
> against it spreading to the rest of the xen tools.

I agree with not using autoconf, however, you should definitely use
"./configure".  Just write it as a simple shell script, as various
projects such as qemu and nfsim do.

Cheers,
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

Re: tidy up requested

[Anthony Liguori]

Ok, I'm writing up the patch for this right now.  Just want to confirm 
the following is all sane:

Ian Pratt wrote:

>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
>
>  
>
/usr/lib/libxenctl.so.3.0.0
/usr/lib/libxenctl.a
/usr/lib/libxenstore.a
/usr/lib/libxenstore-pic.a

Why are we installed libxenstore as a PIC .a and a normal .a and not as 
just a shared object and a normal .a?

>I guess the above are OK.  Makes me wander whether we should
>rename libxc to libxenc ???
>
>./usr/include/xc.h
>./usr/include/xs.h
>./usr/include/xs_lib.h
>./usr/include/xcs_proto.h
>  
>
/usr/include/xen/xenctl.h
/usr/include/xen/xenstore.h
/usr/include/xen/xenstore_lib.h

(we no longer need to install xcs_proto.h)

Everything else on Ian's list seems to be universally agreed upon.

Regards,

Anthony Liguori

>Should the above be under a /usr/include/xen too?
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>  
>

Re: tidy up requested

[Keir Fraser]

> Ok, I'm writing up the patch for this right now.  Just want to confirm 
> the following is all sane:
> 
> Ian Pratt wrote:
> 
> >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
> >
> >  
> >
> /usr/lib/libxenctl.so.3.0.0
> /usr/lib/libxenctl.a
> /usr/lib/libxenstore.a
> /usr/lib/libxenstore-pic.a
> 
> Why are we installed libxenstore as a PIC .a and a normal .a and not as 
> just a shared object and a normal .a?

We build only libxenstore.so now (no .a at all).

 -- Keir