Re: [PATCH] libxen-3.0 (libxc rewrite)

[Jacob Gorm Hansen <jacobg@diku.dk>]

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