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... :-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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/binxm 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/bootIt 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. __________________________________________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt wrote:> ./etc/xen/scripts/network <- rename to network-bridgeThis 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 <-- deleteYep.> ./usr/sbin/xm <-- move to /usr/binNah, I think we should keep user-accessible control tools under /usr/sbin.> ./usr/sbin/xend > ./usr/sbin/xenperf <-- move to /usr/lib/xen/binYep.> ./usr/sbin/xcs (about to be deleted) > ./usr/sbin/xcsdump <-- move to /usr/lib/xen/bin > ./usr/sbin/xenconsoled <-- move to /usr/lib/xen/sbinHang 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/binYep.> ./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 installedOK...> ./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/binHmmm... 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/xenconsoleBzzzt! 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-bridgeOK.> ./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/bootFine.> ./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__.pycSeem 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.htmlSeem reasonable also.> ./usr/share/doc/xen/html/user/labels.pl > ./usr/share/doc/xen/html/user/images.plDon''t know what these do - who uses them?> ./usr/share/doc/xen/html/user/user.cssYup.> ./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@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt wrote:> ./etc/xen/qemu-ifup <- move to /etc/xen/scripts/ok.> ./etc/xen/qemu-vgaram-bin <- move to /usr/lib/xen/bootWill delete this one. We always go through the vmxloader now. -Arun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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/sbinI 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> >>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.Yep, it would be good to fix this. It would enable both the 32 bit and 64 bit tools to be installed on the same 32 bit file system, which is useful for the test CD. Thanks, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. __________________________________________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> >>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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel