* Re: tidy up requested
2005-08-10 16:44 tidy up requested Ian Pratt
@ 2005-08-10 18:31 ` Ronald G Minnich
2005-08-10 19:51 ` Sean Dague
` (5 subsequent siblings)
6 siblings, 0 replies; 22+ messages in thread
From: Ronald G Minnich @ 2005-08-10 18:31 UTC (permalink / raw)
To: Ian Pratt; +Cc: 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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: tidy up requested
2005-08-10 16:44 tidy up requested Ian Pratt
2005-08-10 18:31 ` Ronald G Minnich
@ 2005-08-10 19:51 ` Sean Dague
2005-08-10 20:31 ` Nivedita Singhvi
` (4 subsequent siblings)
6 siblings, 0 replies; 22+ messages in thread
From: Sean Dague @ 2005-08-10 19:51 UTC (permalink / raw)
To: Ian Pratt; +Cc: xen-devel
[-- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: tidy up requested
2005-08-10 16:44 tidy up requested Ian Pratt
2005-08-10 18:31 ` Ronald G Minnich
2005-08-10 19:51 ` Sean Dague
@ 2005-08-10 20:31 ` Nivedita Singhvi
2005-08-10 22:21 ` Mark Williamson
` (3 subsequent siblings)
6 siblings, 0 replies; 22+ messages in thread
From: Nivedita Singhvi @ 2005-08-10 20:31 UTC (permalink / raw)
To: Ian Pratt; +Cc: xen-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: tidy up requested
2005-08-10 16:44 tidy up requested Ian Pratt
` (2 preceding siblings ...)
2005-08-10 20:31 ` Nivedita Singhvi
@ 2005-08-10 22:21 ` Mark Williamson
2005-08-10 23:02 ` Ronald G Minnich
2005-08-10 23:09 ` Anthony Liguori
[not found] ` <mailman.1123692266.16478@unix-os.sc.intel.com>
` (2 subsequent siblings)
6 siblings, 2 replies; 22+ messages in thread
From: Mark Williamson @ 2005-08-10 22:21 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Pratt
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: tidy up requested
2005-08-10 22:21 ` Mark Williamson
@ 2005-08-10 23:02 ` Ronald G Minnich
2005-08-10 23:08 ` Andi Kleen
2005-08-11 1:46 ` Mark Williamson
2005-08-10 23:09 ` Anthony Liguori
1 sibling, 2 replies; 22+ messages in thread
From: Ronald G Minnich @ 2005-08-10 23:02 UTC (permalink / raw)
To: Mark Williamson; +Cc: xen-devel, Ian Pratt
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: tidy up requested
2005-08-10 23:02 ` Ronald G Minnich
@ 2005-08-10 23:08 ` Andi Kleen
2005-08-10 23:14 ` Anthony Liguori
2005-08-11 1:46 ` Mark Williamson
1 sibling, 1 reply; 22+ messages in thread
From: Andi Kleen @ 2005-08-10 23:08 UTC (permalink / raw)
To: Ronald G Minnich; +Cc: xen-devel, Ian Pratt
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: tidy up requested
2005-08-10 23:08 ` Andi Kleen
@ 2005-08-10 23:14 ` Anthony Liguori
2005-08-11 13:18 ` Daniel Hulme
0 siblings, 1 reply; 22+ messages in thread
From: Anthony Liguori @ 2005-08-10 23:14 UTC (permalink / raw)
To: Andi Kleen; +Cc: Ian Pratt, xen-devel, Ronald G Minnich
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
>
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: tidy up requested
2005-08-10 23:14 ` Anthony Liguori
@ 2005-08-11 13:18 ` Daniel Hulme
0 siblings, 0 replies; 22+ messages in thread
From: Daniel Hulme @ 2005-08-11 13:18 UTC (permalink / raw)
To: xen-devel
[-- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: tidy up requested
2005-08-10 23:02 ` Ronald G Minnich
2005-08-10 23:08 ` Andi Kleen
@ 2005-08-11 1:46 ` Mark Williamson
1 sibling, 0 replies; 22+ messages in thread
From: Mark Williamson @ 2005-08-11 1:46 UTC (permalink / raw)
To: Ronald G Minnich; +Cc: xen-devel, Ian Pratt
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: tidy up requested
2005-08-10 22:21 ` Mark Williamson
2005-08-10 23:02 ` Ronald G Minnich
@ 2005-08-10 23:09 ` Anthony Liguori
2005-08-11 11:36 ` Jacob Gorm Hansen
1 sibling, 1 reply; 22+ messages in thread
From: Anthony Liguori @ 2005-08-10 23:09 UTC (permalink / raw)
To: Mark Williamson; +Cc: xen-devel, Ian Pratt
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
>
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: tidy up requested
2005-08-10 23:09 ` Anthony Liguori
@ 2005-08-11 11:36 ` Jacob Gorm Hansen
2005-08-11 12:20 ` Sean Dague
0 siblings, 1 reply; 22+ messages in thread
From: Jacob Gorm Hansen @ 2005-08-11 11:36 UTC (permalink / raw)
To: Anthony Liguori; +Cc: 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: tidy up requested
2005-08-11 11:36 ` Jacob Gorm Hansen
@ 2005-08-11 12:20 ` Sean Dague
2005-08-11 12:38 ` Jacob Gorm Hansen
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Sean Dague @ 2005-08-11 12:20 UTC (permalink / raw)
To: Jacob Gorm Hansen; +Cc: xen-devel
[-- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Re: tidy up requested
2005-08-11 12:20 ` Sean Dague
@ 2005-08-11 12:38 ` Jacob Gorm Hansen
2005-08-12 7:06 ` Rusty Russell
2005-08-11 12:55 ` Jacob Gorm Hansen
2005-08-11 14:10 ` Jacob Gorm Hansen
2 siblings, 1 reply; 22+ messages in thread
From: Jacob Gorm Hansen @ 2005-08-11 12:38 UTC (permalink / raw)
To: Sean Dague; +Cc: 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: tidy up requested
2005-08-11 12:38 ` Jacob Gorm Hansen
@ 2005-08-12 7:06 ` Rusty Russell
0 siblings, 0 replies; 22+ messages in thread
From: Rusty Russell @ 2005-08-12 7:06 UTC (permalink / raw)
To: Jacob Gorm Hansen; +Cc: xen-devel, Sean Dague
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: tidy up requested
2005-08-11 12:20 ` Sean Dague
2005-08-11 12:38 ` Jacob Gorm Hansen
@ 2005-08-11 12:55 ` Jacob Gorm Hansen
2005-08-11 14:10 ` Jacob Gorm Hansen
2 siblings, 0 replies; 22+ messages in thread
From: Jacob Gorm Hansen @ 2005-08-11 12:55 UTC (permalink / raw)
To: Sean Dague; +Cc: 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: tidy up requested
2005-08-11 12:20 ` Sean Dague
2005-08-11 12:38 ` Jacob Gorm Hansen
2005-08-11 12:55 ` Jacob Gorm Hansen
@ 2005-08-11 14:10 ` Jacob Gorm Hansen
2 siblings, 0 replies; 22+ messages in thread
From: Jacob Gorm Hansen @ 2005-08-11 14:10 UTC (permalink / raw)
To: Sean Dague; +Cc: 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
^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <mailman.1123692266.16478@unix-os.sc.intel.com>]
* Re: tidy up requested
2005-08-10 16:44 tidy up requested Ian Pratt
` (4 preceding siblings ...)
[not found] ` <mailman.1123692266.16478@unix-os.sc.intel.com>
@ 2005-08-11 2:08 ` Rusty Russell
2005-08-22 18:10 ` Anthony Liguori
6 siblings, 0 replies; 22+ messages in thread
From: Rusty Russell @ 2005-08-11 2:08 UTC (permalink / raw)
To: Ian Pratt; +Cc: 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.
> ./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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: tidy up requested
2005-08-10 16:44 tidy up requested Ian Pratt
` (5 preceding siblings ...)
2005-08-11 2:08 ` Rusty Russell
@ 2005-08-22 18:10 ` Anthony Liguori
2005-08-22 18:43 ` Keir Fraser
6 siblings, 1 reply; 22+ messages in thread
From: Anthony Liguori @ 2005-08-22 18:10 UTC (permalink / raw)
To: Ian Pratt; +Cc: Rusty Russell, 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
>
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: tidy up requested
2005-08-22 18:10 ` Anthony Liguori
@ 2005-08-22 18:43 ` Keir Fraser
0 siblings, 0 replies; 22+ messages in thread
From: Keir Fraser @ 2005-08-22 18:43 UTC (permalink / raw)
To: Anthony Liguori; +Cc: Rusty Russell, Ian Pratt, 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
^ permalink raw reply [flat|nested] 22+ messages in thread