All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Fred Isaman <iisaman@umich.edu>
Cc: Andy Adamson <andros@netapp.com>, linux-nfs@vger.kernel.org
Subject: Re: pNFS client structure and function rename suggestions
Date: Wed, 28 Jul 2010 17:12:05 +0300	[thread overview]
Message-ID: <4C503AB5.1090204@panasas.com> (raw)
In-Reply-To: <AANLkTikf-9UDhi6_Jg0k8=wV64=JPGVm5T=scQk14xM1@mail.gmail.com>

On 07/28/2010 04:48 PM, Fred Isaman wrote:
> On Wed, Jul 28, 2010 at 7:09 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>>> struct nfs4_pnfs_layout_segment => pnfs_layout_range
>>
>> Isn't this a struct layout4 above?
> 
> No, this is probably the most confusingly named structure of them all,
> and one I would strongly urge be changed along the line of Andy's
> suggestion.
> 
> Fred
> 

We are like a married couple on a freezing night. Each pulling the blanket
to his/her side.

I'm trying to pull the blanket to the side. where all these are converted
to exactly the names and structures as stated by the standard.
That the Linux-pnfs-workgroup tried to invent their own STD is a misfortune
which I missed, getting so late into the game.

What side of the Bed are you pulling to?
I wish you elaborate more, and explain, instead of just saying "NO"

struct layout_content {
           layouttype4 loc_type;
           void      *loc_body;
};

struct layout {
           offset4                 lo_offset;
           length4                 lo_length;
           layoutiomode4           lo_iomode;
           layout_content4         lo_content;
};

struct layoutget_args {
           /* CURRENT_FH: file */
           bool                    loga_signal_layout_avail;
           layouttype4             loga_layout_type;
           layoutiomode4           loga_iomode;
           offset4                 loga_offset;
           length4                 loga_length;
           length4                 loga_minlength;
           stateid4                loga_stateid;
           count4                  loga_maxcount;
};

struct layoutget_res {
           bool               logr_return_on_close;
           stateid4           logr_stateid;
           layout             logr_layout;
};

How is the above less useful then the mess we have now?

Boaz

  reply	other threads:[~2010-07-28 14:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-27 15:38 pNFS client structure and function rename suggestions Andy Adamson
2010-07-28 11:09 ` Boaz Harrosh
2010-07-28 13:48   ` Fred Isaman
2010-07-28 14:12     ` Boaz Harrosh [this message]
2010-07-28 14:29       ` Fred Isaman
2010-07-28 15:10         ` Boaz Harrosh
2010-08-02 14:39           ` Benny Halevy
2010-08-02 15:29             ` Andy Adamson

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=4C503AB5.1090204@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=andros@netapp.com \
    --cc=iisaman@umich.edu \
    --cc=linux-nfs@vger.kernel.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.