| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] libxen-3.0 (libxc rewrite)
Anthony Liguori wrote:
Hi all,
I've been doing a lot of work on libxc. I've got it to the point that
I'm ready to share. Below are the major changes. Feedback is greatly
appreciated, especially with respect to things that would be required
for it to be integrated into the xen-unstable tree.
o Rename libxc => libxen
Is there any good reason for this? Will this include renaming all the
xc_* symbols as well? This will break a lot of code in a lot of places,
so I think the motivation needs to be more than just feel-good value.
o Use pkg-config to control versioning and parallel installs
Don't know what that is or why I need it, but I suppose that means yet
another dependency added. I am against adding dependencies. Used to be I
could just untar xen and type make, now I need to install most of
f*cking Gnome, that horrible Twisted-library and I don't know what, I
think we are headed in the wrong direction with all this. This is a
kernel-level project, not Freshmeat Greatest.
o Use autoconf to detect dependencies, provide separate build directory,
cross-compile
I like having a separate build-directory, I still think at non-broken
build tool (i.e. not make) could have done the job and done it better.
The whole .d or .deps approach (pollution of source or build-tree with a
static version of information that could and should be determined at
run-time) is a gross hack, even MS Visual Studio can do better.
Here is my (a little out of date) Jamfile for libxc btw:
-----------------
SubDir TOP tools libxc ;
SubDirHdrs $(TOP) tools libxutil ;
Library libxc :
xc_atropos.c
xc_bvtsched.c
xc_domain.c
xc_evtchn.c
xc_io.c
xc_linux_build.c
xc_linux_restore.c
xc_linux_save.c
xc_misc.c
xc_physdev.c
xc_plan9_build.c
xc_private.c
xc_rrobin.c
;
------------------
o Use doxygen to autogenerate HTML documentation
Will this be optional, or part of the standard build process? Will the
comments still be human-readable? If find the code and comments in libxc
fairly easy to read and understand inline, isn't doxygen overkill for
this small amount of code? Will I be able to build xen and libxc without
installing doxygen on my system?
o Organize hypercalls by groups in separate headers (dom.h, evtchn.h,
etc.).
o Provide consistent error semantics for all functions (-errno is
returned on error).
Fine with me.
o Use pyrex to autogenerate python bindings
If it reduces the code size I guess it makes sense, hopefully I will
still be able to compile the raw library without compiling the bindings,
and without having pyrex installed? Please also consider that sometimes
I and others need to build (not run, obviously) this stuff on boxes
where we do not have root-access, and the more stuff that needs to be
installed, the less likely this is to work. This is not a contrived
example, when I visited Cambridge (yes, the home of Xen) last year, I
was doing Xen-development from a regular user account, without having
root-access.
I still like vm-tools though :-)
Best regards,
Jacob
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home