From: Paul Mackerras <paulus@samba.org>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Arnd Bergmann <arnd@arndb.de>,
linuxppc64-dev@ozlabs.org, linux-kernel@vger.kernel.org,
arjan@infradead.org, viro@ftp.linux.org.uk
Subject: Re: [PATCH 02/14] spufs: fix local store page refcounting
Date: Wed, 7 Dec 2005 09:19:28 +1100 [thread overview]
Message-ID: <17302.3696.364669.18755@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <1133905298.8027.13.camel@localhost>
Pekka Enberg writes:
> I think the fact that it is highly architecture specific is relevant. I
> have no way of testing spufs changes except on cell, no? And if I am
> developing on a cell, I probably will notice it in arch/ all the same.
> So I don't quite buy your the maintenace argument.
Think about someone changing the VFS layer interface and fixing up all
the filesystems to accommodate that change. That person is doing some
of your work for you, so you want to make it easy for him/her to find
your filesystem. That's the sort of thing I was referring to as
maintenance.
As for changes on the cell-specific side, the people doing those
changes will know where to find it, so it isn't a problem having it in
fs/.
Having it in fs/ also means that it is more likely that people
familiar with VFS internals will look through your code and comment on
it. I know that can be painful in the short term, but in the long
term it will lead to better code.
Paul.
next prev parent reply other threads:[~2005-12-06 22:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20051206035220.097737000@localhost>
[not found] ` <200512061118.19633.arnd@arndb.de>
[not found] ` <1133869108.7968.1.camel@localhost>
2005-12-06 18:49 ` Arnd Bergmann
2005-12-06 19:05 ` Pekka Enberg
2005-12-06 21:10 ` Paul Mackerras
2005-12-06 21:41 ` Pekka Enberg
2005-12-06 22:19 ` Paul Mackerras [this message]
2005-12-06 22:27 ` Arnd Bergmann
2005-12-07 2:26 ` Al Viro
2005-12-07 3:15 ` Paul Mackerras
2005-12-07 8:21 ` Pekka Enberg
2005-12-07 10:17 ` Al Viro
2005-12-06 22:14 ` Nathan Lynch
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=17302.3696.364669.18755@cargo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=arjan@infradead.org \
--cc=arnd@arndb.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc64-dev@ozlabs.org \
--cc=penberg@cs.helsinki.fi \
--cc=viro@ftp.linux.org.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
all inboxes | Powered by JetHome®