From: Christoph Hellwig <hch@infradead.org>
To: Barry Naujok <bnaujok@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>, xfs-dev <xfs-dev@sgi.com>
Subject: Re: [REVIEW] cleanup - remove bhv_vname_t
Date: Tue, 8 Apr 2008 03:41:06 -0400 [thread overview]
Message-ID: <20080408074106.GA3207@infradead.org> (raw)
In-Reply-To: <op.t895ac193jf8g2@pc-bnaujok.melbourne.sgi.com>
On Tue, Apr 08, 2008 at 04:50:26PM +1000, Barry Naujok wrote:
>>> +static inline struct xfs_name *
>>> +xfs_dentry_name(
>>> + struct xfs_name *namep,
>>> + struct dentry *dentry)
>>> +{
>>> + namep->name = dentry->d_name.name;
>>> + namep->len = dentry->d_name.len;
>>> + return namep;
>>> +}
>>
>> As mentioned in my comment to the CI series: shouldn't you just use
>> a struct qstr instead of adding a new struct xfs_name?
>
> Keeping a clean line between fs/xfs and fs/xfs/linux-2.6.
But this means more stack useage and more copies in every namespace
related operation. I don'y yhink it's a good tradeoff.
If you really care about a clear separatation add a #define or typedef
for xfs_name to struct qstr.
>> Also please don't add inline for this.
>>> +xfs_name_t xfs_name_dotdot = {"..", 2};
>>
>> const?
>
> I should change all calls using xfs_name to use const xfs_name?
I just mean this global variable should be declared const. Then
again all the xfs_name arguments are immutable, so it might be worth
marking them const.
next prev parent reply other threads:[~2008-04-08 7:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-08 4:50 [REVIEW] cleanup - remove bhv_vname_t Barry Naujok
2008-04-08 5:13 ` David Chinner
2008-04-08 6:38 ` Christoph Hellwig
2008-04-08 6:50 ` Barry Naujok
2008-04-08 7:41 ` Christoph Hellwig [this message]
2008-04-08 7:48 ` Barry Naujok
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=20080408074106.GA3207@infradead.org \
--to=hch@infradead.org \
--cc=bnaujok@sgi.com \
--cc=xfs-dev@sgi.com \
--cc=xfs@oss.sgi.com \
/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