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

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

Keir Fraser wrote:

>
> On 21 Mar 2005, at 21:25, Anthony Liguori wrote:
>
>> 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.
>
>
> Is there a particular reason for opening /proc/xen/privcmd on every 
> invocation, rather than keeping a handle 

It's not opened on every invocation.  It uses lazy evaluation to only 
open it once for the library.  I should have perhaps documented that a 
little better.

> continuously open? Also I rather liked the xc_ name tags: the tag was 
> a nice indication that I had reached the 

I don't mind adding a common prefix back.  Do other agree with this?  
What about using xen_ instead of xc_?

> bottom of a tools call path and was about to hit Xen. The -errno 
> return values are bizarre: user space has the errno variable for 
> conveying this information.

I can't speak for every library, but I think it's pretty rare to 
actually return errno in userspace.  It just makes life so much easier.

> Overall the library seems to be a greater modification of libxc than I 
> would have thought necessary. It basically looks like a rewrite to 
> pretty much the same interface but with names and copyrights changed.

The goals were to provide a interface tightly tied to the actual 
hypercalls.  I know it's probably a lot more than you expected but there 
were a lot of problems with libxc.  I can attest to this from trying to 
develop tools off of them.

Here were some of the problems with libxc:

1) Inconsistent errors
   - some calls returned errno from the hypercall, some returned errno 
from the call that failed, some set errno themselves, some never touched 
errno and made calls that would squash the hypercall's errno.
   - some calls just printf()'d an error message and squashed errno

2) Inconsistent mlock()'ing
   - some functions required arguments to be mlock()'d and some did it 
for you.

3) Poor typing
   - some functions used the wrong types in the interface (like passing 
an int instead of a domid_t for xc_domain_create()).

4) Lack of documentation

5) Poor developer support
   - Assumes headers and libs are in /usr/{include, lib}

So, making all of these changes touched every function.  Especially 
documenting every error condition.  So it was significantly easier to 
just start with fresh code.

>  -- Keir
>
>



-------------------------------------------------------
This SF.net email is sponsored by: 2005 Windows Mobile Application Contest
Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones
for the chance to win $25,000 and application distribution. Enter today at
http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click