|
xen-devel
Re: [Xen-devel] [PATCH] libxen-3.0 (libxc rewrite)
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
Home