From: Benny Halevy <bhalevy@tonian.com>
To: Marc Eshel <eshel@us.ibm.com>
Cc: "J. Bruce Fields" <bfields@redhat.com>,
linux-nfs@vger.kernel.org,
Trond Myklebust <trond.myklebust@netapp.com>,
Trond Myklebust <trond.myklebust@netapp.com>
Subject: Re: notify_deviceid_type4
Date: Tue, 11 Dec 2012 13:20:50 +0200 [thread overview]
Message-ID: <50C71712.2030909@tonian.com> (raw)
In-Reply-To: <OF0F796F1E.99986A09-ON88257ACF.0063225B-88257ACF.0063629E@us.ibm.com>
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@tonian.com>
> To: Marc Eshel/Almaden/IBM@IBMUS,
> Cc: linux-nfs-owner@vger.kernel.org, Trond Myklebust
> <trond.myklebust@netapp.com>, linux-nfs@vger.kernel.org, "J. Bruce Fields"
> <bfields@redhat.com>
> 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@us.ibm.com> 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@tonian.com> wrote on 12/09/2012 01:42:47 AM:
>
>> From: Benny Halevy <bhalevy@tonian.com>
>> To: Marc Eshel/Almaden/IBM@IBMUS,
>> Cc: Trond Myklebust <Trond.Myklebust@netapp.com>, "J. Bruce Fields"
>> <bfields@redhat.com>, linux-nfs-owner@vger.kernel.org, linux-
>> nfs@vger.kernel.org
>> 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@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>
>
--
Benny Halevy
CTO, Tonian Inc.
Tel: +972-54-802-8340
bhalevy@tonian.com
next prev parent reply other threads:[~2012-12-11 11:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-01 5:54 notify_deviceid_type4 Marc Eshel
2012-12-09 9:42 ` notify_deviceid_type4 Benny Halevy
2012-12-09 16:43 ` notify_deviceid_type4 Marc Eshel
[not found] ` <CAEMWVhsh0SvLX8MY8cghOmbYExpqFLYgUFVuai_RyaYu3EErvw@mail.gmail.com>
2012-12-09 18:05 ` notify_deviceid_type4 Marc Eshel
[not found] ` <CAEMWVhv3GwJh1nTNYeCm4AnrDVdZbrJLS4DeKn4C6iHkJ5-jbA@mail.gmail.com>
2012-12-09 21:46 ` notify_deviceid_type4 Marc Eshel
2012-12-10 2:51 ` notify_deviceid_type4 Marc Eshel
2012-12-11 11:20 ` Benny Halevy [this message]
2012-12-11 19:01 ` notify_deviceid_type4 Marc Eshel
[not found] <OFF752FE87.86716271-ON88257AC7.002025E3-88257AC7.00206C04@LocalDomain>
[not found] ` <OF13B342CA.3B3F39AC-ON88257ACD.0080BC4F-88257ACD.00815AED@LocalDomain>
2012-12-07 23:46 ` notify_deviceid_type4 Marc Eshel
[not found] ` <OF13B342CA.3B3F39AC-ON88257ACD.0080BC4F-88257ACD.00815B0B@us.ibm.com>
[not found] ` <4FA345DA4F4AE44899BD2B03EEEC2FA90B33D909@SACEXCMBX04-PRD.hq.netapp.com>
2012-12-08 0:10 ` notify_deviceid_type4 Marc Eshel
2012-12-08 1:24 ` notify_deviceid_type4 Jim Rees
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50C71712.2030909@tonian.com \
--to=bhalevy@tonian.com \
--cc=bfields@redhat.com \
--cc=eshel@us.ibm.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@netapp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.