linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Charles Manning <manningc2@actrix.gen.nz>
Cc: Christoph Hellwig <hch@infradead.org>,
	Charles Manning <cdhmanning@gmail.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	ryan@bluewatersys.com, akpm@linux-foundation.org
Subject: Re: [PATCH 0/10] Add yaffs2 file system:  Fifth patchset
Date: Wed, 16 Feb 2011 03:04:20 -0500	[thread overview]
Message-ID: <20110216080419.GA21261@infradead.org> (raw)
In-Reply-To: <201102100722.47854.manningc2@actrix.gen.nz>

On Thu, Feb 10, 2011 at 07:22:47AM +1300, Charles Manning wrote:
> Can you be a bit more specific?

Just compare the mes in yaffs_linux.c with a normal linux filesystem.
All that gross magic nfsd detection in readdir could have been removed
long ago.  ->readlink should not be implemented by a normal filesystem
but use generic_readlink, the fs-specific inode should embedd the vfs
inode instead of requiring two allocations, tons of useless function
pointer indirections like sb_dirty_fn and the put_super_fn really must
go away.  The procfs interfaces should be replaced by something saner,
the insane amount of ad-hoc tracing crap should be replaced by much
less strategically placed trace events, and all those stupid compile
time options have absolutely no business at all beeing there for a
filesystem - remember you can get media from all over the place.
If you can't encode these difference in your on-disk format it has
absolutely no business going into mainline with this format.

And last but not least there's no way we'll merge a filesystem with a
global mutex and all kinds of hacky release and reaquire semantics
these days.  I really think you need to get back to the drawing board.

  reply	other threads:[~2011-02-16  8:04 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-09  3:25 [PATCH 0/10] Add yaffs2 file system: Fifth patchset Charles Manning
2011-02-09  3:25 ` [PATCH 01/10] Add yaffs2 file system: allocators, bitmap and block handling Charles Manning
2011-02-09  3:26 ` [PATCH 02/10] Add yaffs2 file system: attrib and xattrib handling Charles Manning
2011-02-09 22:33   ` Ryan Mallon
2011-02-09  3:26 ` [PATCH 03/10] Add yaffs2 file system: checkpoint streaming Charles Manning
2011-02-10 22:27   ` Jesper Juhl
2011-02-10 22:44     ` Ryan Mallon
2011-02-10 22:50       ` Charles Manning
2011-02-09  3:26 ` [PATCH 04/10] Add yaffs2 file system: flash interface and ecc handling Charles Manning
2011-02-09  3:26 ` [PATCH 05/10] Add yaffs2 file system: tags handling Charles Manning
2011-02-09  3:26 ` [PATCH 06/10] Add yaffs2 file system: tracing and verification handling Charles Manning
2011-02-11 23:01   ` Ryan Mallon
2011-02-09  3:26 ` [PATCH 07/10] Add yaffs2 file system: yaffs1 and yaffs2 mode handling Charles Manning
2011-02-09  3:26 ` [PATCH 08/10] Add yaffs2 file system: core guts code Charles Manning
2011-02-10  2:27   ` Ryan Mallon
2011-02-09  3:26 ` [PATCH 09/10] Add yaffs2 file system: Linux glue code Charles Manning
2011-02-10 22:07   ` Ryan Mallon
2011-02-10 22:47     ` Charles Manning
2011-02-17 22:24   ` Ryan Mallon
2011-02-09  3:26 ` [PATCH 10/10] Add yaffs2 file system: hok in to Linux tree Charles Manning
2011-02-09  4:52 ` [PATCH 0/10] Add yaffs2 file system: Fifth patchset Christoph Hellwig
2011-02-09 18:22   ` Charles Manning
2011-02-16  8:04     ` Christoph Hellwig [this message]
2011-02-16 22:12       ` Charles Manning
2011-02-17  1:48         ` Mark Brown
2011-02-17  2:31           ` Charles Manning
2011-02-17  2:52             ` Ryan Mallon
2011-02-17  3:49               ` Charles Manning
2011-02-17 23:41                 ` Greg KH
2011-02-18  0:01                   ` Mark Brown
2011-02-18  0:33                     ` Greg KH
2011-02-18  0:43                       ` Mark Brown
2011-02-18  0:55                         ` Ryan Mallon
2011-02-18  0:58                           ` Greg KH
2011-02-20 17:25                             ` Charles Manning
2011-02-20 20:07                               ` Greg KH
2011-02-20 20:52                                 ` Ryan Mallon
2011-02-20 22:29                                   ` Greg KH
2011-02-20 22:57                                     ` Ryan Mallon
2011-02-18  1:08                           ` Mark Brown
2011-02-17  3:49             ` Mark Brown
2011-02-17  4:22               ` Charles Manning
2011-02-17  6:08                 ` Mark Brown
2011-02-19 17:45         ` Pavel Machek
2011-08-17 12:12 ` Linus Walleij

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=20110216080419.GA21261@infradead.org \
    --to=hch@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=cdhmanning@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manningc2@actrix.gen.nz \
    --cc=ryan@bluewatersys.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;
as well as URLs for NNTP newsgroup(s).