* Re: notify_deviceid_type4 [not found] ` <OF13B342CA.3B3F39AC-ON88257ACD.0080BC4F-88257ACD.00815AED@LocalDomain> @ 2012-12-07 23:46 ` Marc Eshel 0 siblings, 0 replies; 11+ messages in thread From: Marc Eshel @ 2012-12-07 23:46 UTC (permalink / raw) To: Myklebust, Trond; +Cc: J. Bruce Fields, linux-nfs, linux-nfs-owner Trond, can you please apply the following patch so we are in compliance with the spec. Thanks, Marc. diff --git a/include/linux/nfs4.h b/include/linux/nfs4.h index 59cc833..ad32df5 100644 --- a/include/linux/nfs4.h +++ b/include/linux/nfs4.h @@ -499,8 +499,8 @@ enum pnfs_iomode { }; enum pnfs_notify_deviceid_type4 { - NOTIFY_DEVICEID4_CHANGE = 1 << 1, - NOTIFY_DEVICEID4_DELETE = 1 << 2, + NOTIFY_DEVICEID4_CHANGE = 1, + NOTIFY_DEVICEID4_DELETE = 2, }; #define NFL4_UFLG_MASK 0x0000003F ------------------------------------------------------------------------------------------------------------- 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 }; ^ permalink raw reply related [flat|nested] 11+ messages in thread
[parent not found: <OF13B342CA.3B3F39AC-ON88257ACD.0080BC4F-88257ACD.00815B0B@us.ibm.com>]
[parent not found: <4FA345DA4F4AE44899BD2B03EEEC2FA90B33D909@SACEXCMBX04-PRD.hq.netapp.com>]
* RE: notify_deviceid_type4 [not found] ` <4FA345DA4F4AE44899BD2B03EEEC2FA90B33D909@SACEXCMBX04-PRD.hq.netapp.com> @ 2012-12-08 0:10 ` Marc Eshel 2012-12-08 1:24 ` notify_deviceid_type4 Jim Rees 0 siblings, 1 reply; 11+ messages in thread From: Marc Eshel @ 2012-12-08 0:10 UTC (permalink / raw) To: Myklebust, Trond; +Cc: linux-nfs@vger.kernel.org Y29tbWl0IDEwMTNlMmVhODgzODRkYTJlNzMyNmY0MDA0N2JiYzkyZGViOWU1MTYNCkF1dGhvcjog TWFyYyBFc2hlbCA8ZXNoZWxAYWxtYWRlbi5pYm0uY29tPg0KRGF0ZTogICBGcmkgRGVjIDcgMTU6 NTg6MDcgMjAxMiAtMDgwMA0KDQpDaGFuZ2UgZGVmaW5pdGlvbiBvZiBub3RpZnlfZGV2aWNlaWRf dHlwZTQgdG8gY29ycmVzcG9uZCB0byB0aGUgTkZTdjQuMSANCnNwZWMuDQoNClNpZ25lZC1vZmYt Ynk6IE1hcmMgRXNoZWwgPGVzaGVsQHVzLmlibS5jb20+DQotLS0NCg0KZGlmZiAtLWdpdCBhL2lu Y2x1ZGUvbGludXgvbmZzNC5oIGIvaW5jbHVkZS9saW51eC9uZnM0LmgNCmluZGV4IDU5Y2M4MzMu LmFkMzJkZjUgMTAwNjQ0DQotLS0gYS9pbmNsdWRlL2xpbnV4L25mczQuaA0KKysrIGIvaW5jbHVk ZS9saW51eC9uZnM0LmgNCkBAIC00OTksOCArNDk5LDggQEAgZW51bSBwbmZzX2lvbW9kZSB7DQog fTsNCg0KIGVudW0gcG5mc19ub3RpZnlfZGV2aWNlaWRfdHlwZTQgew0KLSAgICAgICBOT1RJRllf REVWSUNFSUQ0X0NIQU5HRSA9IDEgPDwgMSwNCi0gICAgICAgTk9USUZZX0RFVklDRUlENF9ERUxF VEUgPSAxIDw8IDIsDQorICAgICAgIE5PVElGWV9ERVZJQ0VJRDRfQ0hBTkdFID0gMSwNCisgICAg ICAgTk9USUZZX0RFVklDRUlENF9ERUxFVEUgPSAyLA0KIH07DQoNCiAjZGVmaW5lIE5GTDRfVUZM R19NQVNLICAgICAgICAgICAgICAgICAweDAwMDAwMDNGDQoNCg0KDQpGcm9tOiAgICJNeWtsZWJ1 c3QsIFRyb25kIiA8VHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20+DQpUbzogICAgIE1hcmMgRXNo ZWwvQWxtYWRlbi9JQk1ASUJNVVMsIA0KQ2M6ICAgICAiSi4gQnJ1Y2UgRmllbGRzIiA8YmZpZWxk c0ByZWRoYXQuY29tPiwgDQoibGludXgtbmZzQHZnZXIua2VybmVsLm9yZyIgPGxpbnV4LW5mc0B2 Z2VyLmtlcm5lbC5vcmc+LCANCiJsaW51eC1uZnMtb3duZXJAdmdlci5rZXJuZWwub3JnIiA8bGlu dXgtbmZzLW93bmVyQHZnZXIua2VybmVsLm9yZz4NCkRhdGU6ICAgMTIvMDcvMjAxMiAwMzo0NSBQ TQ0KU3ViamVjdDogICAgICAgIFJFOiBub3RpZnlfZGV2aWNlaWRfdHlwZTQNCg0KDQoNCkhpIE1h cmMsDQogDQpJ4oCZdmUgYmVlbiB3YWl0aW5nIGZvciBhIHBhdGNoIGZyb20geW91IGZvciB0aGlz IChJIHNhdyB5b3VyIG9yaWdpbmFsIGJ1ZyANCnJlcG9ydCkuIENvdWxkIHlvdSBwbGVhc2UgcmVz ZW5kIHdpdGggYSBmb3JtYWwgY2hhbmdlbG9nIGVudHJ5IGFuZCANCnNpZ25lZC1vZmYtYnkgbGlu ZT8gSSBrbm93IHRoYXQgd291bGQgbWFrZSB5b3VyIGxlZ2FsIGNvbGxlYWd1ZXMgaW4gSUJNIA0K dmVyeSBoYXBweS4gSg0KIA0KQ2hlZXJzDQogIFRyb25kDQogDQpGcm9tOiBNYXJjIEVzaGVsIFtt YWlsdG86ZXNoZWxAdXMuaWJtLmNvbV0gDQpTZW50OiBTYXR1cmRheSwgRGVjZW1iZXIgMDgsIDIw MTIgMTI6MzMgQU0NClRvOiBNeWtsZWJ1c3QsIFRyb25kDQpDYzogSi4gQnJ1Y2UgRmllbGRzOyBs aW51eC1uZnNAdmdlci5rZXJuZWwub3JnOyANCmxpbnV4LW5mcy1vd25lckB2Z2VyLmtlcm5lbC5v cmcNClN1YmplY3Q6IFJlOiBub3RpZnlfZGV2aWNlaWRfdHlwZTQNCiANClRyb25kLCBjYW4geW91 IHBsZWFzZSBhcHBseSB0aGUgZm9sbG93aW5nIHBhdGNoIHNvIHdlIGFyZSBpbiBjb21wbGlhbmNl IA0Kd2l0aCB0aGUgc3BlYy4gDQpUaGFua3MsIE1hcmMuIA0KDQpkaWZmIC0tZ2l0IGEvaW5jbHVk ZS9saW51eC9uZnM0LmggYi9pbmNsdWRlL2xpbnV4L25mczQuaCANCmluZGV4IDU5Y2M4MzMuLmFk MzJkZjUgMTAwNjQ0IA0KLS0tIGEvaW5jbHVkZS9saW51eC9uZnM0LmggDQorKysgYi9pbmNsdWRl L2xpbnV4L25mczQuaCANCkBAIC00OTksOCArNDk5LDggQEAgZW51bSBwbmZzX2lvbW9kZSB7IA0K IH07IA0KICANCiBlbnVtIHBuZnNfbm90aWZ5X2RldmljZWlkX3R5cGU0IHsgDQotICAgICAgIE5P VElGWV9ERVZJQ0VJRDRfQ0hBTkdFID0gMSA8PCAxLCANCi0gICAgICAgTk9USUZZX0RFVklDRUlE NF9ERUxFVEUgPSAxIDw8IDIsIA0KKyAgICAgICBOT1RJRllfREVWSUNFSUQ0X0NIQU5HRSA9IDEs IA0KKyAgICAgICBOT1RJRllfREVWSUNFSUQ0X0RFTEVURSA9IDIsIA0KIH07IA0KICANCiAjZGVm aW5lIE5GTDRfVUZMR19NQVNLICAgICAgICAgICAgICAgICAweDAwMDAwMDNGIA0KDQoNCg0KRnJv bTogICAgICAgIE1hcmMgRXNoZWwvQWxtYWRlbi9JQk0gDQpUbzogICAgICAgICJUcm9uZCBNeWts ZWJ1c3QiIDxUcm9uZC5NeWtsZWJ1c3RAbmV0YXBwLmNvbT4sICJKLiBCcnVjZSANCkZpZWxkcyIg PGJmaWVsZHNAcmVkaGF0LmNvbT4sIA0KQ2M6ICAgICAgICBsaW51eC1uZnMtb3duZXJAdmdlci5r ZXJuZWwub3JnLCBsaW51eC1uZnNAdmdlci5rZXJuZWwub3JnIA0KRGF0ZTogICAgICAgIDExLzMw LzIwMTIgMDk6NTQgUE0gDQpTdWJqZWN0OiAgICAgICAgbm90aWZ5X2RldmljZWlkX3R5cGU0IA0K DQoNCg0KVGhlIHNwZWMgZGVmaW5lcyBub3RpZnlfZGV2aWNlaWRfdHlwZTQgYXM6IA0KDQoyMC4x Mi4xLiAgQVJHVU1FTlQNCiAgLyoNCiAgICogRGV2aWNlIG5vdGlmaWNhdGlvbiB0eXBlcy4NCiAg ICovDQogIGVudW0gbm90aWZ5X2RldmljZWlkX3R5cGU0IHsNCiAgICAgICAgICBOT1RJRllfREVW SUNFSUQ0X0NIQU5HRSA9IDEsDQogICAgICAgICAgTk9USUZZX0RFVklDRUlENF9ERUxFVEUgPSAy DQogIH07IA0KDQoNCmJ1dCB0aGUgTGludXggY29kZSBpbiBuZnM0LmggaGFzLCBpcyB0aGF0IGdv aW5nIHRvIGJlIGZpeGVkPyANCg0KZW51bSBwbmZzX25vdGlmeV9kZXZpY2VpZF90eXBlNCB7IA0K ICAgICAgICBOT1RJRllfREVWSUNFSUQ0X0NIQU5HRSA9IDEgPDwgMSwgDQogICAgICAgIE5PVElG WV9ERVZJQ0VJRDRfREVMRVRFID0gMSA8PCAyLCANCn07IA0KDQo= ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: notify_deviceid_type4 2012-12-08 0:10 ` notify_deviceid_type4 Marc Eshel @ 2012-12-08 1:24 ` Jim Rees 0 siblings, 0 replies; 11+ messages in thread From: Jim Rees @ 2012-12-08 1:24 UTC (permalink / raw) To: Marc Eshel; +Cc: Myklebust, Trond, linux-nfs@vger.kernel.org Marc Eshel wrote: commit 1013e2ea88384da2e7326f40047bbc92deb9e516 Author: Marc Eshel <eshel@almaden.ibm.com> Date: Fri Dec 7 15:58:07 2012 -0800 Change definition of notify_deviceid_type4 to correspond to the NFSv4.1 spec. Doesn't apply for me: % git am ~/Mail/tmp/89 Applying: RE: notify_deviceid_type4 fatal: corrupt patch at line 9 Patch failed at 0001 RE: notify_deviceid_type4 When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". ^ permalink raw reply [flat|nested] 11+ messages in thread
* notify_deviceid_type4
@ 2012-12-01 5:54 Marc Eshel
2012-12-09 9:42 ` notify_deviceid_type4 Benny Halevy
0 siblings, 1 reply; 11+ messages in thread
From: Marc Eshel @ 2012-12-01 5:54 UTC (permalink / raw)
To: Trond Myklebust, J. Bruce Fields; +Cc: linux-nfs-owner, linux-nfs
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,
};
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: notify_deviceid_type4 2012-12-01 5:54 notify_deviceid_type4 Marc Eshel @ 2012-12-09 9:42 ` Benny Halevy 2012-12-09 16:43 ` notify_deviceid_type4 Marc Eshel 0 siblings, 1 reply; 11+ messages in thread From: Benny Halevy @ 2012-12-09 9:42 UTC (permalink / raw) To: Marc Eshel; +Cc: Trond Myklebust, J. Bruce Fields, linux-nfs-owner, linux-nfs 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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: notify_deviceid_type4 2012-12-09 9:42 ` notify_deviceid_type4 Benny Halevy @ 2012-12-09 16:43 ` Marc Eshel [not found] ` <CAEMWVhsh0SvLX8MY8cghOmbYExpqFLYgUFVuai_RyaYu3EErvw@mail.gmail.com> 0 siblings, 1 reply; 11+ messages in thread From: Marc Eshel @ 2012-12-09 16:43 UTC (permalink / raw) To: Benny Halevy; +Cc: J. Bruce Fields, linux-nfs, linux-nfs-owner, Trond Myklebust 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 > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <CAEMWVhsh0SvLX8MY8cghOmbYExpqFLYgUFVuai_RyaYu3EErvw@mail.gmail.com>]
* Re: notify_deviceid_type4 [not found] ` <CAEMWVhsh0SvLX8MY8cghOmbYExpqFLYgUFVuai_RyaYu3EErvw@mail.gmail.com> @ 2012-12-09 18:05 ` Marc Eshel [not found] ` <CAEMWVhv3GwJh1nTNYeCm4AnrDVdZbrJLS4DeKn4C6iHkJ5-jbA@mail.gmail.com> 2012-12-11 11:20 ` notify_deviceid_type4 Benny Halevy 0 siblings, 2 replies; 11+ messages in thread From: Marc Eshel @ 2012-12-09 18:05 UTC (permalink / raw) To: Benny Halevy; +Cc: J. Bruce Fields, linux-nfs, linux-nfs-owner, Trond Myklebust Can you provide with the spec information that supports your interpretation? 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 > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <CAEMWVhv3GwJh1nTNYeCm4AnrDVdZbrJLS4DeKn4C6iHkJ5-jbA@mail.gmail.com>]
* Re: notify_deviceid_type4 [not found] ` <CAEMWVhv3GwJh1nTNYeCm4AnrDVdZbrJLS4DeKn4C6iHkJ5-jbA@mail.gmail.com> @ 2012-12-09 21:46 ` Marc Eshel 2012-12-10 2:51 ` notify_deviceid_type4 Marc Eshel 1 sibling, 0 replies; 11+ messages in thread From: Marc Eshel @ 2012-12-09 21:46 UTC (permalink / raw) To: Benny Halevy; +Cc: J. Bruce Fields, NFS list, linux-nfs-owner, Trond Myklebust So you are saying it should be: enum pnfs_notify_deviceid_type4 { NOTIFY_DEVICEID4_CHANGE = 1 << 0, NOTIFY_DEVICEID4_DELETE = 1 << 1, }; From: Benny Halevy <bhalevy@tonian.com> To: Marc Eshel/Almaden/IBM@IBMUS, Cc: linux-nfs-owner@vger.kernel.org, NFS list <linux-nfs@vger.kernel.org>, "J. Bruce Fields" <bfields@redhat.com>, Trond Myklebust <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> wrote: Can you provide with the spec information that supports your interpretation? 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 > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: notify_deviceid_type4 [not found] ` <CAEMWVhv3GwJh1nTNYeCm4AnrDVdZbrJLS4DeKn4C6iHkJ5-jbA@mail.gmail.com> 2012-12-09 21:46 ` notify_deviceid_type4 Marc Eshel @ 2012-12-10 2:51 ` Marc Eshel 1 sibling, 0 replies; 11+ messages in thread From: Marc Eshel @ 2012-12-10 2:51 UTC (permalink / raw) To: Benny Halevy; +Cc: J. Bruce Fields, NFS list, linux-nfs-owner, Trond Myklebust I don't see that we are following notify_type4 either. notify_type4 is enum 0,1,2,3,.... so notify_deviceid_type4 should be enum 0,1 or 1,2 since it was already defined this way in the spec. Defining it as 2, 4 make no sense if it is a bit number, way skip bits?. The use of shift is used for bit mask which you claim it is not. Marc. From: Benny Halevy <bhalevy@tonian.com> To: Marc Eshel/Almaden/IBM@IBMUS, Cc: linux-nfs-owner@vger.kernel.org, NFS list <linux-nfs@vger.kernel.org>, "J. Bruce Fields" <bfields@redhat.com>, Trond Myklebust <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> wrote: Can you provide with the spec information that supports your interpretation? 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 > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: notify_deviceid_type4 2012-12-09 18:05 ` notify_deviceid_type4 Marc Eshel [not found] ` <CAEMWVhv3GwJh1nTNYeCm4AnrDVdZbrJLS4DeKn4C6iHkJ5-jbA@mail.gmail.com> @ 2012-12-11 11:20 ` Benny Halevy 2012-12-11 19:01 ` notify_deviceid_type4 Marc Eshel 1 sibling, 1 reply; 11+ messages in thread From: Benny Halevy @ 2012-12-11 11:20 UTC (permalink / raw) To: Marc Eshel; +Cc: J. Bruce Fields, linux-nfs, Trond Myklebust, Trond Myklebust 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: notify_deviceid_type4 2012-12-11 11:20 ` notify_deviceid_type4 Benny Halevy @ 2012-12-11 19:01 ` Marc Eshel 0 siblings, 0 replies; 11+ messages in thread From: Marc Eshel @ 2012-12-11 19:01 UTC (permalink / raw) To: Benny Halevy; +Cc: J. Bruce Fields, linux-nfs, Trond Myklebust, nfsv4 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@tonian.com> wrote on 12/11/2012 03:20:50 AM: > From: Benny Halevy <bhalevy@tonian.com> > To: Marc Eshel/Almaden/IBM@IBMUS, > Cc: "J. Bruce Fields" <bfields@redhat.com>, linux- > nfs@vger.kernel.org, Trond Myklebust <trond.myklebust@netapp.com>, > Trond Myklebust <trond.myklebust@netapp.com> > 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@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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-12-11 19:01 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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
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 ` notify_deviceid_type4 Benny Halevy
2012-12-11 19:01 ` notify_deviceid_type4 Marc Eshel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).