Re: [XenPPC] [xenppc-unstable] [ppc] Handle 2 forms of NULL gues handle

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

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