Re: [Xen-changelog] [xen-unstable] [IA64] fix xencomm_handle_is_null().

[Hollis Blanchard <hollisb@us.ibm.com>]

On Wed, 2006-11-15 at 00:40 +0000, Xen patchbot-unstable wrote:
> # HG changeset patch
> # User awilliam@xenbuild.aw
> # Node ID 3713ea43e6364bf2989a1cf0dc252a6a1393ce02
> # Parent  8533c59c5b40df0f6e6d03cbc8a74057dcbed5db
> [IA64] fix xencomm_handle_is_null().
> 
> It checks only desc->address[0]. However xencomm_add_offset() may
> sets XENCOMM_INVALID while there left consumable bytes.
> In such a case xencomm_handle_is_null() returns true wrongly.
> 
> Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
> ---
>  xen/arch/ia64/xen/xencomm.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff -r 8533c59c5b40 -r 3713ea43e636 xen/arch/ia64/xen/xencomm.c
> --- a/xen/arch/ia64/xen/xencomm.c	Fri Nov 10 11:14:36 2006 -0700
> +++ b/xen/arch/ia64/xen/xencomm.c	Fri Nov 10 11:14:42 2006 -0700
> @@ -382,6 +382,6 @@ xencomm_handle_is_null(
>              return 1;
> 
>          desc = (struct xencomm_desc *)desc_addr;
> -        return (desc->address[0] == XENCOMM_INVALID);
> -    }
> -}
> +        return (desc->nr_addrs == 0);
> +    }
> +}

I think I'm missing something. Why did IA64 fork xencomm?

I distinctly remember having conversations about sharing the code, which
is obviously the right thing to do.

-- 
Hollis Blanchard
IBM Linux Technology Center