Can you provide with the spec information that supports your
interpretation?
Marc.
From: Benny Halevy <[email protected]>
To: Marc Eshel/Almaden/IBM@IBMUS,
Cc: [email protected], Trond Myklebust
<[email protected]>, [email protected], "J. Bruce Fields"
<[email protected]>
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 protected]> 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 protected]> wrote on 12/09/2012 01:42:47 AM:
> From: Benny Halevy <[email protected]>
> To: Marc Eshel/Almaden/IBM@IBMUS,
> Cc: Trond Myklebust <[email protected]>, "J. Bruce Fields"
> <[email protected]>, [email protected], linux-
> [email protected]
> 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 protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
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 protected]>
> To: Marc Eshel/Almaden/IBM@IBMUS,
> Cc: [email protected], Trond Myklebust
> <[email protected]>, [email protected], "J. Bruce Fields"
> <[email protected]>
> 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 protected]> 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 protected]> wrote on 12/09/2012 01:42:47 AM:
>
>> From: Benny Halevy <[email protected]>
>> To: Marc Eshel/Almaden/IBM@IBMUS,
>> Cc: Trond Myklebust <[email protected]>, "J. Bruce Fields"
>> <[email protected]>, [email protected], linux-
>> [email protected]
>> 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 protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>
>
--
Benny Halevy
CTO, Tonian Inc.
Tel: +972-54-802-8340
[email protected]
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 protected]> wrote on 12/11/2012 03:20:50 AM:
> From: Benny Halevy <[email protected]>
> To: Marc Eshel/Almaden/IBM@IBMUS,
> Cc: "J. Bruce Fields" <[email protected]>, linux-
> [email protected], Trond Myklebust <[email protected]>,
> Trond Myklebust <[email protected]>
> 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 protected]>
> > To: Marc Eshel/Almaden/IBM@IBMUS,
> > Cc: [email protected], Trond Myklebust
> > <[email protected]>, [email protected], "J. Bruce
Fields"
> > <[email protected]>
> > 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 protected]> 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 protected]> wrote on 12/09/2012 01:42:47 AM:
> >
> >> From: Benny Halevy <[email protected]>
> >> To: Marc Eshel/Almaden/IBM@IBMUS,
> >> Cc: Trond Myklebust <[email protected]>, "J. Bruce Fields"
> >> <[email protected]>, [email protected], linux-
> >> [email protected]
> >> 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 protected]
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>
> >>
> >
> >
>
> --
> Benny Halevy
> CTO, Tonian Inc.
>
> Tel: +972-54-802-8340
> [email protected]
>