linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).