public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alex Elder <aelder@sgi.com>,
	linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
	akpm@linux-foundation.org
Subject: Re: [GIT PULL] XFS update for 3.1-rc4
Date: Wed, 24 Aug 2011 10:42:06 +1000	[thread overview]
Message-ID: <20110824004206.GG3162@dastard> (raw)
In-Reply-To: <CA+55aFxEyj8qJnr9QR3Scy7SFocEr2BNA9z4PXs7q9rpkXM1vQ@mail.gmail.com>

On Tue, Aug 23, 2011 at 11:46:30AM -0700, Linus Torvalds wrote:
> On Tue, Aug 23, 2011 at 10:39 AM, Alex Elder <aelder@sgi.com> wrote:
> >
> > Linus, please pull the following XFS changes.  Their effect is to
> > remove the subdirectory structure from the XFS source hierarchy.
> > There are no functional changes to the XFS code itself.  Thanks.
> 
> Pulled.
> 
> Any plans to further sanitize the namespace?
> 
> It's kind of crazy to have filenames like
> 
>    fs/xfs/xfs_trace.c
> 
> which just duplicate the "xfs" part for no good reason.

I consider the context it adds to cscope searches a damn good reason
for keeping it.

> Why not just
> do something like
> 
>   for i in xfs_*; do j=$(echo $i | sed 's/^xfs_//'); git mv $i $j; done
> 
> to get rid of the silly "xfs_" prefix that adds nothing?

Because that then kills context that is actually useful in cscope
searches. That is, every filesystem has the file "inode.c",
"super.c", etc and so you can't tell from the cscope searchs which
filesystem function calls belong to. 

Duplicate name spaces are evil, and we have a lot of them in the
filesystem tree - if they all had explicit namespacing like XFS
does, then the world would be a better place. ;)


> You could use the bytes you save to rename "qm.c" to "quota_manager.c"
> instead. Wouldn't it be nice to have *good* names, instead of a jumble
> of crazy and mostly redundant letters?

The names make sense to anyone who has spent any time in the XFS
code. The name of the file reflects the namespace of the code inside
the file itself. e.g. to use the xfs_qm.c as an example:

$ grep ^xfs_qm_  fs/xfs/xfs_qm.c
xfs_qm_destroy(
xfs_qm_hold_quotafs_ref(
xfs_qm_rele_quotafs_ref(
xfs_qm_unmount(
xfs_qm_mount_quotas(
xfs_qm_unmount_quotas(
xfs_qm_dqflush_all(
xfs_qm_detach_gdquots(
xfs_qm_dqpurge_int(
xfs_qm_dqpurge_all(
xfs_qm_dqattach_one(
xfs_qm_dqattach_grouphint(
xfs_qm_dqattach_locked(
xfs_qm_dqattach(
xfs_qm_dqdetach(
xfs_qm_sync(
xfs_qm_init_quotainfo(
xfs_qm_destroy_quotainfo(
xfs_qm_list_init(
xfs_qm_list_destroy(
xfs_qm_qino_alloc(
xfs_qm_reset_dqcounts(
xfs_qm_dqiter_bufs(
xfs_qm_dqiterate(
xfs_qm_quotacheck_dqadjust(
xfs_qm_get_rtblks(
xfs_qm_dqusage_adjust(
xfs_qm_quotacheck(
xfs_qm_init_quotainos(
xfs_qm_dqreclaim_one(void)
xfs_qm_shake_freelist(
xfs_qm_shake_scan(
xfs_qm_shake_count(
xfs_qm_dqalloc_incore(
xfs_qm_write_sb_changes(
xfs_qm_vop_dqalloc(
xfs_qm_vop_chown(
xfs_qm_vop_chown_reserve(
xfs_qm_vop_rename_dqattach(
xfs_qm_vop_create_dqattach(

So there is a certain methodic sanity to the naming convention that
is not immediately obvious from just looking at the file names, and
that's a good reason not to change them.

Besides, I don't want to have to spend 3 months reprogramming
my muscle memory just because we painted the bikeshed a different
colour. ;)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2011-08-24  0:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-23 17:39 [GIT PULL] XFS update for 3.1-rc4 Alex Elder
2011-08-23 18:46 ` Linus Torvalds
2011-08-23 19:57   ` Alex Elder
2011-08-24  0:42   ` Dave Chinner [this message]
2011-08-24  0:59     ` Linus Torvalds
2011-08-24  7:42       ` Dave Chinner

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=20110824004206.GG3162@dastard \
    --to=david@fromorbit.com \
    --cc=aelder@sgi.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --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