From: Benny Halevy <bhalevy@tonian.com>
To: NFS list <linux-nfs@vger.kernel.org>
Cc: Marc Eshel <eshel@us.ibm.com>,
"J. Bruce Fields" <bfields@redhat.com>,
Trond Myklebust <trond.myklebust@netapp.com>
Subject: Fwd: Re: notify_deviceid_type4
Date: Mon, 10 Dec 2012 14:01:02 +0200 [thread overview]
Message-ID: <50C5CEFE.6090107@tonian.com> (raw)
In-Reply-To: <CAEMWVhtv8LXqVjctmGDkc4bDCQ_V7_caL5HxN3t7MvPPVd58WQ@mail.gmail.com>
Sorry, my original post was bounced due to containing html.
Forwarding to the list.
Benny
-------- Original Message --------
Subject: Re: notify_deviceid_type4
Date: Mon, 10 Dec 2012 08:57:29 +0200
From: Benny Halevy <bhalevy@tonian.com>
To: Marc Eshel <eshel@us.ibm.com>
CC: NFS list <linux-nfs@vger.kernel.org>, Trond Myklebust <trond.myklebust@netapp.com>, "J. Bruce Fields" <bfields@redhat.com>, linux-nfs-owner@vger.kernel.org
On Dec 9, 2012 11:47 PM, "Marc Eshel" <eshel@us.ibm.com <mailto:eshel@us.ibm.com>> wrote:
>
> So you are saying it should be:
>
> enum pnfs_notify_deviceid_type4 {
> NOTIFY_DEVICEID4_CHANGE = 1 << 0,
> NOTIFY_DEVICEID4_DELETE = 1 << 1,
> };
Maybe theoretically but the spec already defined it skipping the first bit. I'm not sure why. Probably just a mistake.
Benny
>
>
>
> From: Benny Halevy <bhalevy@tonian.com <mailto:bhalevy@tonian.com>>
> To: Marc Eshel/Almaden/IBM@IBMUS,
> Cc: linux-nfs-owner@vger.kernel.org <mailto:linux-nfs-owner@vger.kernel.org>, NFS list
> <linux-nfs@vger.kernel.org <mailto:linux-nfs@vger.kernel.org>>, "J. Bruce Fields" <bfields@redhat.com <mailto:bfields@redhat.com>>, Trond
> Myklebust <trond.myklebust@netapp.com <mailto:trond.myklebust@netapp.com>>
> Date: 12/09/2012 11:54 AM
> Subject: Re: notify_deviceid_type4
>
>
>
> I'm not sure if and whete that's saud explicitly but another example to
> support that inrerpretation are the values of notify_type4 that apply to
> the same bitmap that too are defined as sequential numbers (though zero
> based) and not as single bit masks.
> Benny
> On Dec 9, 2012 8:05 PM, "Marc Eshel" <eshel@us.ibm.com <mailto:eshel@us.ibm.com>> wrote:
> Can you provide with the spec information that supports your
> interpretation?
> Marc.
>
>
>
> From: Benny Halevy <bhalevy@tonian.com <mailto:bhalevy@tonian.com>>
> To: Marc Eshel/Almaden/IBM@IBMUS,
> Cc: linux-nfs-owner@vger.kernel.org <mailto:linux-nfs-owner@vger.kernel.org>, Trond Myklebust
> <trond.myklebust@netapp.com <mailto:trond.myklebust@netapp.com>>, linux-nfs@vger.kernel.org <mailto:linux-nfs@vger.kernel.org>, "J. Bruce Fields"
> <bfields@redhat.com <mailto: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 <mailto: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 <mailto:bhalevy@tonian.com>> wrote on 12/09/2012 01:42:47 AM:
>
> > From: Benny Halevy <bhalevy@tonian.com <mailto:bhalevy@tonian.com>>
> > To: Marc Eshel/Almaden/IBM@IBMUS,
> > Cc: Trond Myklebust <Trond.Myklebust@netapp.com <mailto:Trond.Myklebust@netapp.com>>, "J. Bruce Fields"
> > <bfields@redhat.com <mailto:bfields@redhat.com>>, linux-nfs-owner@vger.kernel.org <mailto:linux-nfs-owner@vger.kernel.org>, linux-
> > nfs@vger.kernel.org <mailto: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 <mailto:majordomo@vger.kernel.org>
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > >
> >
>
>
>
parent reply other threads:[~2012-12-10 12:01 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <CAEMWVhtv8LXqVjctmGDkc4bDCQ_V7_caL5HxN3t7MvPPVd58WQ@mail.gmail.com>]
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=50C5CEFE.6090107@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.