From: Boaz Harrosh <bharrosh@panasas.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Benny Halevy <bhalevy@panasas.com>,
NFS list <linux-nfs@vger.kernel.org>,
pNFS Mailing List <pnfs@linux-nfs.org>
Subject: Re: [pnfs] [PATCH RFC v2 0/21] nfs4xdr cleanup v2
Date: Mon, 17 Aug 2009 16:54:45 +0300 [thread overview]
Message-ID: <4A896125.2040506@panasas.com> (raw)
In-Reply-To: <1250513254.8475.20.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
On 08/17/2009 03:47 PM, Trond Myklebust wrote:
> On Mon, 2009-08-17 at 13:40 +0300, Boaz Harrosh wrote:
>> * So I hate it that the READ32/WRITE32 is open coded. Now it looks like nothing, it
>> should have an xdr_encode/decode naming convention, all details hidden, consistent calling
>> convention with the reset of the code.
>
> The convention is already established. Please see 15 years worth of
> NFSv2/v3 xdr code. The NFSv4 code was the exception not the rule.
>
> Now, it is obvious what we're doing: we're writing 32-bit big endian
> encoded data into a memory buffer. Furthermore, the process of
> converting from cpu ordered integers into 32-bit big endian is now made
> obvious, making it easily verifiable both by inspection, and using
> 'sparse'.
> Adding wrappers to do this, is just unnecessarily obfuscating the code.
>
As I said, *sometimes* "obfuscation" is the point. If it has merits to account
for human short concentration span.
>> * I hate it that I have to count (p)"++" now to look for actual code advancements.
>
> How is that _any_ different from counting WRITE32s?
>
The size for one. And mainly the symmetry with the other side of the wire.
WRITEXX for every READXX. What now?
>> * I hate that it is called encode_hyper that a dum like me needs to look it up in the dictionary
>> "32" and "64" will do
>
> I don't mind changing the name of xdr_encode_hyper() to
> xdr_encode_uint64 or some such alternative, however the point is that we
> should have only _one_ function that encodes 64 bit integers. Not one
> function that everyone else uses, and then a macro that NFSv4 uses.
>
>> * I hated it before, but I hate it even more now that the same operation is:
>> reserved(4); p + 1
>
> Huh? What operation?
>
Sorry, I meant the mix use of byte_sizes and word_sizes. For example I'd like
reserved(1); p + 1;
and reserved(quad_len(len)); p + quad_len(len);
I see a pattern here. Highly changing code devises these "helpers", that enables
reviewing, for catching bugs. Then once stabilized, code is "un-obfuscated" and
becomes "write-only". Who cares, no one needs to read-it, it works.
I don't want to raise any flame wars here. I come late and I see what I see.
Probably 2, 3 iterations into this I will become blind to this code as well.
I guess current code is fine. How hard can it be, so I spend an hour longer on
a missing "++". New NFS versions are written every 10 years.
Only one request though. Please make nfs and nfsd use the same xdr mechanics
Boaz
next prev parent reply other threads:[~2009-08-17 13:54 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-14 14:17 [PATCH RFC v2 0/21] nfs4xdr cleanup v2 Benny Halevy
2009-08-14 14:18 ` [PATCH RFC v2 01/21] sunrpc: hton -> cpu_to_be* Benny Halevy
2009-08-14 14:18 ` [PATCH RFC v2 02/21] sunrpc: ntoh -> be*_to_cpu Benny Halevy
2009-08-14 14:18 ` [PATCH RFC v2 03/21] nfs: nfs4xdr: get rid of WRITE32 Benny Halevy
2009-08-14 14:19 ` [PATCH RFC v2 04/21] nfs: nfs4xdr: get rid of WRITE64 Benny Halevy
2009-08-14 14:19 ` [PATCH RFC v2 05/21] nfs: nfs4xdr: get rid of WRITEMEM Benny Halevy
2009-08-14 14:19 ` [PATCH RFC v2 06/21] nfs: nfs4xdr: optimize RESERVE_SPACE in encode_create_session and encode_sequence Benny Halevy
2009-08-14 16:32 ` Chuck Lever
2009-08-14 16:57 ` Trond Myklebust
[not found] ` <1250269055.5476.11.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-14 18:49 ` Chuck Lever
2009-08-14 19:28 ` Trond Myklebust
[not found] ` <1250278083.5476.51.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-14 19:48 ` Trond Myklebust
2009-08-14 14:19 ` [PATCH RFC v2 07/21] nfs: nfs4xdr: encode_compound_hdr does not have to round up reserved bytes Benny Halevy
2009-08-14 14:19 ` [PATCH RFC v2 08/21] nfs: nfs4xdr: change RESERVE_SPACE macro into a static helper Benny Halevy
2009-08-14 14:19 ` [PATCH RFC v2 09/21] nfs: nfs4xdr: optimize low level encoding Benny Halevy
2009-08-14 14:19 ` [PATCH RFC v2 10/21] nfs: nfs4xdr: merge xdr_encode_int+xdr_encode_opaque_fixed into xdr_encode_opaque Benny Halevy
2009-08-14 14:19 ` [PATCH RFC v2 11/21] nfs: nfs4xdr: get rid of READ32 Benny Halevy
2009-08-14 14:19 ` [PATCH RFC v2 12/21] nfs: nfs4xdr: get rid of READ64 Benny Halevy
2009-08-14 14:19 ` [PATCH RFC v2 13/21] nfs: nfs4xdr: get rid of READTIME Benny Halevy
2009-08-14 14:19 ` [PATCH RFC v2 14/21] nfs: nfs4xdr: introduce print_overflow_msg Benny Halevy
2009-08-14 14:19 ` [PATCH RFC v2 15/21] nfs: nfs4xdr: introduce decode_opaque_fixed and decode_stateid helpers Benny Halevy
2009-08-14 14:19 ` [PATCH RFC v2 16/21] nfs: nfs4xdr: introduce decode_verifier helper Benny Halevy
2009-08-14 17:54 ` Trond Myklebust
[not found] ` <1250272482.5476.14.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-15 10:27 ` Benny Halevy
2009-08-14 14:20 ` [PATCH RFC v2 17/21] nfs: nfs4xdr: introduce decode_sessionid helper Benny Halevy
2009-08-14 14:20 ` [PATCH RFC v2 18/21] nfs: nfs4xdr: get rid of COPYMEM Benny Halevy
2009-08-14 14:20 ` [PATCH RFC v2 19/21] nfs: nfs4xdr: simplify decode_exchange_id by reusing decode_opaque_inline Benny Halevy
2009-08-14 14:20 ` [PATCH RFC v2 20/21] nfs: nfs4xdr: get rid of READ_BUF Benny Halevy
2009-08-14 14:20 ` [PATCH RFC v2 21/21] nfs: nfs4xdr: optimize low level decoding Benny Halevy
2009-08-17 10:40 ` [pnfs] [PATCH RFC v2 0/21] nfs4xdr cleanup v2 Boaz Harrosh
2009-08-17 12:47 ` Trond Myklebust
[not found] ` <1250513254.8475.20.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-17 13:54 ` Boaz Harrosh [this message]
2009-08-17 16:48 ` Trond Myklebust
[not found] ` <1250527692.20012.26.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-17 16:53 ` J. Bruce Fields
[not found] ` <4A9240C7.5090307@panasas.com>
2009-08-24 11:56 ` Trond Myklebust
[not found] ` <1251115007.6325.9.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-24 12:50 ` Boaz Harrosh
2009-08-24 12:59 ` Trond Myklebust
[not found] ` <1251118754.6325.47.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-24 13:26 ` Boaz Harrosh
2009-08-24 13:50 ` Trond Myklebust
[not found] ` <1251121822.6325.68.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-24 14:42 ` Boaz Harrosh
2009-08-24 13:45 ` Chuck Lever
2009-08-24 17:04 ` Trond Myklebust
[not found] ` <1251133443.6325.260.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-24 18:45 ` Chuck Lever
2009-08-24 19:54 ` Trond Myklebust
2009-08-17 18:22 ` Peter Staubach
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=4A896125.2040506@panasas.com \
--to=bharrosh@panasas.com \
--cc=Trond.Myklebust@netapp.com \
--cc=bhalevy@panasas.com \
--cc=linux-nfs@vger.kernel.org \
--cc=pnfs@linux-nfs.org \
/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 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).