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