From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] libxen-3.0 (libxc rewrite) Date: Mon, 21 Mar 2005 22:24:06 -0600 Message-ID: <423F9DE6.8050204@us.ibm.com> References: <423F3BB5.3020600@us.ibm.com> <423F9216.6040806@diku.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <423F9216.6040806@diku.dk> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Jacob Gorm Hansen Cc: xen-devel List-Id: xen-devel@lists.xenproject.org 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