From: Al Viro <viro@ftp.linux.org.uk>
To: Paul Mackerras <paulus@samba.org>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
Arnd Bergmann <arnd@arndb.de>,
linuxppc64-dev@ozlabs.org, linux-kernel@vger.kernel.org,
arjan@infradead.org
Subject: Re: [PATCH 02/14] spufs: fix local store page refcounting
Date: Wed, 7 Dec 2005 02:26:10 +0000 [thread overview]
Message-ID: <20051207022610.GI27946@ftp.linux.org.uk> (raw)
In-Reply-To: <17302.3696.364669.18755@cargo.ozlabs.ibm.com>
On Wed, Dec 07, 2005 at 09:19:28AM +1100, Paul Mackerras wrote:
> 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.
FWIW, I think it's not a serious argument. Interface changes => grep time.
And that means grep over the tree anyway.
> 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.
That's solved by asking for review...
As far as I'm concerned, the only thing here that looks like a possible
reason to move the entire thing is highly unusual semantics of final
close and interesting use of VFS interfaces in spu_create(). I.e. it's
not that we have a filesystem there.
OTOH, if you go looking for analogs as far as unusual interaction with VFS
is concerned... net/unix is unlikely to get moved.
next prev parent reply other threads:[~2005-12-07 2:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20051206035220.097737000@localhost>
2005-12-06 3:52 ` [PATCH 11/14] spidernet: fix Kconfig after BPA->CELL rename Arnd Bergmann
2005-12-06 3:52 ` [PATCH 12/14] spidernet: check if firmware was loaded correctly Arnd Bergmann
2005-12-06 0:59 ` Paul Mackerras
2005-12-06 10:23 ` Arnd Bergmann
2005-12-07 9:53 ` Jens Osterkamp
2005-12-06 3:52 ` [PATCH 13/14] spidernet: read firmware from the OF device tree Arnd Bergmann
2005-12-06 3:52 ` [PATCH 14/14] spidernet: fix HW structures for 64 bit dma_addr_t Arnd Bergmann
[not found] ` <200512061118.19633.arnd@arndb.de>
[not found] ` <1133869108.7968.1.camel@localhost>
2005-12-06 18:49 ` [PATCH 02/14] spufs: fix local store page refcounting 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
2005-12-06 22:27 ` Arnd Bergmann
2005-12-07 2:26 ` Al Viro [this message]
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=20051207022610.GI27946@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=arjan@infradead.org \
--cc=arnd@arndb.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc64-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=penberg@cs.helsinki.fi \
/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.