Subject: Re: [nfsv4] notify_deviceid_type4

From: Marc Eshel <[email-masked]>
Date: Tue, 11 Dec 2012 11:01:45 -0800

That sound like the correct thing to do, I which we have the agreement 
from all implementations to make sure we all do the same thing. I will 
copy the ietf mailing list to see that there are no objections. I guess we 
will find out in the next cton what breaks.
Marc.

Benny Halevy <[email-masked]> wrote on 12/11/2012 03:20:50 AM:

> From: Benny Halevy <[email-masked]>
> To: Marc Eshel/Almaden/IBM@IBMUS, 
> Cc: "J. Bruce Fields" <[email-masked]>, linux-
> [email-masked], Trond Myklebust <[email-masked]>, 
> Trond Myklebust <[email-masked]>
> Date: 12/11/2012 03:21 AM
> Subject: Re: notify_deviceid_type4
> 
> On 2012-12-09 20:05, Marc Eshel wrote:
> > Can you provide with the spec information that supports your 
> > interpretation?
> 
> Marc, section 18.40.3. says the following:
> 
>    The notification mask is
>    composed in the same manner as the bitmap for file attributes
>    (Section 3.3.7).  The numbers of bit positions are listed in the
>    notify_device_type4 enumeration type (Section 20.12).
> 
> The linux implementation chose to reflect the bit masks in the header
> file rather than the bit numbers but it's clear the masks should equal
> 2 (1<<1) and 4 (1<<2) rather than 1 and 2.
> 
> For clarity, I'm OK with a patch that fixes the definition in nfs4.h to:
> 
> enum pnfs_notify_deviceid_type4 {
>          NOTIFY_DEVICEID4_CHANGE = 1,
>          NOTIFY_DEVICEID4_DELETE = 2,
> };
> 
> But every place these values are currently used verbatim should be fixed
> respectively to use the shifted value, e.g. (1 << 
NOTIFY_DEVICEID4_CHANGE).
> 
> Benny
> 
> > Marc.
> > 
> > 
> > 
> > From:   Benny Halevy <[email-masked]>
> > To:     Marc Eshel/Almaden/IBM@IBMUS, 
> > Cc:     [email-masked], Trond Myklebust 
> > <[email-masked]>, [email-masked], "J. Bruce 
Fields" 
> > <[email-masked]>
> > Date:   12/09/2012 09:50 AM
> > Subject:        Re: notify_deviceid_type4
> > 
> > 
> > 
> > The enum values in the spec correspond to bit _numbers_ in the bitmap, 
not 
> > to bitmasks.
> > On Dec 9, 2012 6:43 PM, "Marc Eshel" <[email-masked]> wrote:
> > I am not sure what you are saying, I am showing the definition from 
the
> > spec. that show NOTIFY_DEVICEID4_CHANGE = 1, and nfs4.h has it as (1<< 
1)
> > which is not 1, it is 2.
> > Marc.
> > 
> > Benny Halevy <[email-masked]> wrote on 12/09/2012 01:42:47 AM:
> > 
> >> From: Benny Halevy <[email-masked]>
> >> To: Marc Eshel/Almaden/IBM@IBMUS,
> >> Cc: Trond Myklebust <[email-masked]>, "J. Bruce Fields"
> >> <[email-masked]>, [email-masked], linux-
> >> [email-masked]
> >> Date: 12/09/2012 01:44 AM
> >> Subject: Re: notify_deviceid_type4
> >>
> >> On 2012-12-01 07:54, Marc Eshel wrote:
> >>> The spec defines notify_deviceid_type4 as:
> >>>
> >>> 20.12.1.  ARGUMENT
> >>>    /*
> >>>     * Device notification types.
> >>>     */
> >>>    enum notify_deviceid_type4 {
> >>>            NOTIFY_DEVICEID4_CHANGE = 1,
> >>>            NOTIFY_DEVICEID4_DELETE = 2
> >>>    };
> >>>
> >>>
> >>> but the Linux code in nfs4.h has, is that going to be fixed?
> >>>
> >>> enum pnfs_notify_deviceid_type4 {
> >>>         NOTIFY_DEVICEID4_CHANGE = 1 << 1,
> >>>         NOTIFY_DEVICEID4_DELETE = 1 << 2,
> >>> };
> >>
> >> notify_deviceid_type4 specifies bit numbers same as notify_type4
> >> It seems to me like the definition in nfs4.h is correct.
> >>
> >> Benny
> >>
> >>>
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> > in
> >>> the body of a message to [email-masked]
> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>
> >>
> > 
> > 
> 
> -- 
> Benny Halevy
> CTO, Tonian Inc.
> 
> Tel: +972-54-802-8340
> [email-masked]
>