| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] libxen-3.0 (libxc rewrite)
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
|
|
|
| |
|
Home