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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 22 Mar 2005, at 17:05, Anthony Liguori wrote:

> There seems to be wide consensus on this one though and I don't seem 
> to have the popular opinion.  So perhaps we can comprimise.  What 
> about:
> 1) Have most functions return an integer.  An error is indicated if 
> the return is < 0.  In the event of an error, the function will return 
> -errno but make sure to set errno properly.
> 2) For functions that want to return addresses, they can do so and 
> return NULL on error.  Since all functions set errno properly, errno 
> will have to be used for extended error conditions on these functions.
> This should make everyone happy.   Your code will work just fine and 
> an application developer can avoid using errno.  Thoughts?
I'll complicate the argument some more by suggesting that errno, and 
the standard errno values, aren't the best things to be returning from 
Xen across the hypercall interface anyway. Many errno values are not 
applicable to a hypervisor; also, if we defined our own then we could 
return a richer set of error notifications to guests and to control 
tools.
Currently EINVAL, EPERM, EFAULT and ESRCH are approx the limit of our 
'richness'.
The reason I used errno's originally in Xen was laziness and time 
constraints. :-)
I guess we'd need strong motivation (some cases where better error 
returns would be really useful) to be bothered to change the status quo 
though.
 -- 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel