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: 46+ 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-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 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.