| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ppc-devel
Re: [XenPPC] [xenppc-unstable] [ppc] Handle 2 forms of NULL gues handle
On Jul 27, 2006, at 5:13 PM, Hollis Blanchard wrote:
On Thu, 2006-07-27 at 16:37 -0400, Jimi Xenidis wrote:
I think the correct solution (pretty sure it would cover it all)
would be to arrange for __xencomm_init(buffer=NULL) to set desc-
nr_addrs = 0, never touching desc->address[] and checking for
(nr_addrs==0) in xencomm_handle_is_null(), also reducing the number
of checks and assignments required to communicate "nothing"
That sounds OK to me.
diff -r 72c8bc5d88f4 drivers/xen/core/xencomm.c
--- a/drivers/xen/core/xencomm.c Thu Jun 29 13:04:30 2006 -0400
+++ b/drivers/xen/core/xencomm.c Thu Jul 27 15:58:58 2006 -0500
@@ -58,6 +58,10 @@ static int __xencomm_init(struct xencomm
{
unsigned long recorded = 0;
int i = 0;
+
+ /* special-case NULL pointers for easy detection on the Xen
side */
+ if (buffer == NULL)
+ desc->nr_addrs = 0;
/* record the physical pages used */
while ((recorded < bytes) && (i < desc->nr_addrs)) {
not so simple because 'bytes' is non-zero and we'll end up reporting
ENOSPC.
I think we still need to "else" the buffer!=NULL case below.
I'll take this an test it.
-JX
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
|
|
| |
|
Home