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 <bhalevy@xxxxxxxxxx> wrote on 12/11/2012 03:20:50 AM:
> From: Benny Halevy <bhalevy@xxxxxxxxxx>
> To: Marc Eshel/Almaden/IBM@IBMUS,
> Cc: "J. Bruce Fields" <bfields@xxxxxxxxxx>, linux-
> nfs@xxxxxxxxxxxxxxx, Trond Myklebust <trond.myklebust@xxxxxxxxxx>,
> Trond Myklebust <trond.myklebust@xxxxxxxxxx>
> 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 <bhalevy@xxxxxxxxxx>
> > To: Marc Eshel/Almaden/IBM@IBMUS,
> > Cc: linux-nfs-owner@xxxxxxxxxxxxxxx, Trond Myklebust
> > <trond.myklebust@xxxxxxxxxx>, linux-nfs@xxxxxxxxxxxxxxx, "J. Bruce
Fields"
> > <bfields@xxxxxxxxxx>
> > 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" <eshel@xxxxxxxxxx> 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 <bhalevy@xxxxxxxxxx> wrote on 12/09/2012 01:42:47 AM:
> >
> >> From: Benny Halevy <bhalevy@xxxxxxxxxx>
> >> To: Marc Eshel/Almaden/IBM@IBMUS,
> >> Cc: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx>, "J. Bruce Fields"
> >> <bfields@xxxxxxxxxx>, linux-nfs-owner@xxxxxxxxxxxxxxx, linux-
> >> nfs@xxxxxxxxxxxxxxx
> >> 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 majordomo@xxxxxxxxxxxxxxx
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>
> >>
> >
> >
>
> --
> Benny Halevy
> CTO, Tonian Inc.
>
> Tel: +972-54-802-8340
> bhalevy@xxxxxxxxxx
>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
