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

[Anthony Liguori <aliguori@us.ibm.com>]

Jacob Gorm Hansen wrote:

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

The API is completely different.  This interface is a thin wrapper 
around the hypercalls.  All the code needs to be rewritten anyway.  I'm 
a big believer that things should be self-documenting.  xc seems like a 
bad prefix because it's pretty much meaningless (I guess it's supposed 
to be xen-control or something).

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

You may be aware that many libraries distribution custom -config 
scripts.  pkg-config is a unified interface for -config scripts.  If 
your system doesn't have pkg-config, no harm is done.  It's not checked 
for in configure because it's not required to build.  If there really is 
a strong desire to have a -config script instead of using pkg-config, 
that's fine.  That seems a bit odd though.

Using pkg-config just means that you put a file in a known location 
(${prefix}/lib/pkgconfig) that describes your libraries CFLAGS and 
LDFLAGS.  Otherwise, you have to install your own -config script in 
${prefix}/bin.

Some sort of -config mechanism is necessary for libraries.  Otherwise, a 
developer has no chance of being able to link against your software 
unless you always install in /usr/include and /usr/lib (which is not a 
very good thing to require).

I feel your pain, I agree with you completely :-)  If you don't believe 
me, take a busy box chroot and ./configure libxen.  Everything will work 
just fine :-)

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

Yes, yes, no, yes.  If you don't have doxygen, it's not used.  The 
comments are as human-readable as they could possibly be.  libxc 
currently has almost no interface level comments.  Documentation of all 
public interfaces is a requirement for EAL certification and doing it 
now with doxygen is going to save a lot of headache in the future when 
someone has to do this.

Not to mention the fact that trying to write a robust management tool 
without interface-level documentation is painful.  It basically requires 
sifting through the Xen code to find which errors can be returned in 
what circumstances.

We basically have three options:

1) Use a standard format for documenting APIs and use a tool to extract 
that documentation
2) Maintain a separate document documenting APIs
3) Sparsely document header files

1 & 2 seem to be the only reasonable things to do, and 1 is going to be 
a lot easier to deal with in the long run.

> 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

Yes.  If you don't have pyrex or python the bindings won't be built.  
Moreover, pyrex generates C code and the build process is completely 
python free so the generated C files could be included as part of the 
source tarballs (much like configure is autogenerated and yet still 
usually included in source tarballs).

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

Yes, that's one of the reasons to use autoconf.  It lets you specify 
non-standard locations for header files so you can do just what you 
describe.

Take a look at this library, I think you'll find that it provides more 
support for the things you're concerned about than libxc currently does.

Regards,
Anthony Liguori


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