linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ronald G. Minnich" <rminnich@lanl.gov>
To: Pekka Enberg <penberg@gmail.com>
Cc: "ericvh@gmail.com" <ericvh@gmail.com>,
	linux-kernel@vger.kernel.org,
	v9fs-developer@lists.sourceforge.net,
	viro@parcelfarce.linux.theplanet.co.uk,
	linux-fsdevel@vger.kernel.org, penberg@cs.helsinki.fi
Subject: Re: [V9fs-developer] Re: [RFC][patch 3/7] v9fs: VFS inode operations (2.0-rc6)
Date: Tue, 24 May 2005 08:08:44 -0600 (MDT)	[thread overview]
Message-ID: <Pine.LNX.4.58.0505240803410.9237@enigma.lanl.gov> (raw)
In-Reply-To: <84144f0205052401432ffa1075@mail.gmail.com>



On Tue, 24 May 2005, Pekka Enberg wrote:

> > +static int
> > +v9fs_vfs_create(struct inode *inode, struct dentry *dentry, int perm,
> > +		struct nameidata *nd)
> > +{
> > +	int retval = -EPERM;
> > +	int open_mode = O_RDWR;
> > +
> > +	retval = v9fs_create(inode, dentry, perm, open_mode);
> > +
> > +	return retval;

> 
> Both local variables are redundant. Please just do:
> 
> 	return v9fs_create(inode, dentry, perm, O_RDWR);
> 
well, here is my first point of disagreement with the many good 
suggestions I have seen. 

I prefer the style as it is, and dislike the return vfs_create(...) 
change. 

First, we're all agreed here that this is a style, not efficiency thing, 
right? Makes no difference, compiler will do what is right. 

The reason I prefer the 'retval = blah blah; return retval;' usage is that
I frequently have run v9fs in UML, and debugging is just easier. Set the
breakpoint in v9fs_vfs_create, step through, maybe skip over that
v9fs_create function, look at retval. Also, should we get to the point
later that we have a debug print of some sort in that function, adding it
is trivial.

I realize there is a preferred style here, but is there room for some 
flexibility?

thanks

ron

  reply	other threads:[~2005-05-24 14:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-23 22:25 [RFC][patch 3/7] v9fs: VFS inode operations (2.0-rc6) ericvh
2005-05-24  8:43 ` Pekka Enberg
2005-05-24 14:08   ` Ronald G. Minnich [this message]
2005-05-24 14:25     ` [V9fs-developer] " Miklos Szeredi
2005-05-24 14:56       ` Ronald G. Minnich

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=Pine.LNX.4.58.0505240803410.9237@enigma.lanl.gov \
    --to=rminnich@lanl.gov \
    --cc=ericvh@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=penberg@gmail.com \
    --cc=v9fs-developer@lists.sourceforge.net \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /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).