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>,
	Chuck Lever <chuck.lever@oracle.com>,
	"J. Bruce Fields" <bfields@citi.umich.edu>,
	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, 24 Aug 2009 17:42:28 +0300	[thread overview]
Message-ID: <4A92A6D4.1060104@panasas.com> (raw)
In-Reply-To: <1251121822.6325.68.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>

On 08/24/2009 04:50 PM, Trond Myklebust wrote:
> On Mon, 2009-08-24 at 16:26 +0300, Boaz Harrosh wrote:
>> On 08/24/2009 03:59 PM, Trond Myklebust wrote:
>>> On Mon, 2009-08-24 at 15:50 +0300, Boaz Harrosh wrote:
>>>> On 08/24/2009 02:56 PM, Trond Myklebust wrote:
>>> In any case, I don't apply patches based on popular vote. I apply them
>>> based on my conviction that they are useful.
>>>
>>
>> I think you need a reality check. Just look in the mailing list archives.
> 
> No Boaz. YOU need the reality check.
> 
> As I said above, I don't apply patches based on popular vote. I'm open
> to be persuaded that something is useful and helps maintainability of
> the code, 

No you are not open. We tell you it helps us, and your unswer is "it does
not help me". But you are narrow minded on the NFS code, when some of us
come from other parts and would like a distinction.

> but I'm not open to coercive tactics such as people telling me
> that I'm being irrational, and that I should do what the "Big
> Majority" (consisting so far of 2 people) wants.
> 

3-to-1 in this thread only, I've search the archives, every once in a while
the subject comes up and patches are submitted, and you are the only one to
object.

There is no coercive tactics. "coercive tactics" would be to snick in the code
through some other tree. I'm trying to convince you that there are other points
of views and that it would help all bunch of people. That we like it on merits
other than pure computer-science but for ease of read/writing and a means to make
our life easier. You see no point in it, but maybe we do. For our sake, you should
consider it.

>>> I mean that the fundamental type of XDR is a __be32. We are using that
>>> fundamental type in standard C code.
>>
>> I heavily use beXX types in code totally unrelated to XDR. Please don't hijack
>> _beXX to mean XDR, for me they are just unrelated overlapping subjects.
> 
> ??? We don't have a special 'XDR' type, and I didn't say '__beXX' is
> XDR. I said that the fundamental type that we use in XDR encoding and
> decoding is a __b32. That's why you get to declare
> 
> 	__be32 *p;
> 
> at the top of each XDR function.

I was not saying XDR type. Sure the type is __be32. I was talking about
ease of use and calling convention symmetry.

> Then you get to encode the contents of
> that '__be32' declared memory location using the standard Linux C
> functions for manipulating '__be32' type.
> 

No! you get to use all these xdr_{en,de}code_xx functions, except for the
"int type" which you do something else because ... Please look at the code.
They stand out as the exception not the rule.

> If you don't like the names of those standard functions, then complain
> to the people who named them.
> 

It's not the names I don't like, it's the calling convention.

>>> The fundamental Linux function for converting from a u32 to a __be32 is
>>> cpu_to_be32(). It doesn't need a new wrapper, and neither does
>>> be32_to_cpu().
>>>
>>
>> And that is exactlly why I use them inside "my" xdr-wrapper. But the xdr wrapper
>> for me is to do with calling convention, uniformity of code, and statement of intent.
>> My wrapper is not about byte-ness it is about calling convention and that pointer arithmetic
>> which you don't like, and I do.
> 
> I repeat: we don't have a special 'XDR' type. We have __be32.
> 

Where do you see the word "type" in my sentence above. I said: calling convention, naming convention,
statement of intent. I said nothing about types.

I will keep looking at this code and keep writing this code, and will weep every time.
I wish there was some pill I could take that will make me not feel bad about this. Perhaps
I'll just get numb after a long while. Maybe that was the: "a bit early for you"

sincerely yours
Boaz

  parent reply	other threads:[~2009-08-24 14:42 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
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 [this message]
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=4A92A6D4.1060104@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=bfields@citi.umich.edu \
    --cc=bhalevy@panasas.com \
    --cc=chuck.lever@oracle.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).