[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimS-x-+JGvpEbHcWyEMcp-nCno8kwuaBAcTjDnV@mail.gmail.com>
Date: Tue, 22 Mar 2011 10:30:30 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
apw@...onical.com, nbd@...nwrt.org, neilb@...e.de
Subject: Re: [PATCH 4/6 v7] overlay filesystem prototype
On Tue, Mar 22, 2011 at 8:26 AM, Miklos Szeredi <miklos@...redi.hu> wrote:
>
> fs/Kconfig | 1
> fs/Makefile | 1
> fs/overlayfs/Kconfig | 4
> fs/overlayfs/Makefile | 5
> fs/overlayfs/overlayfs.c | 2394 +++++++++++++++++++++++++++++++++++++++++++++++
> 5 files changed, 2405 insertions(+)
Just one single C file? Is there no structure to the code at all? No
separate issues for directory lookup vs file operations, no helper
libraries vs core ops? No "mount time" vs "runtime" structure to the
code?
So 2400 lines isn't all that much, but things have a tendency to grow.
So when I see one single file that tries to do everything, I go "hmm".
Normal filesystems tend to have super.c for handling the mount itself,
and dir.c vs file.c for directory ops vs file ops. Maybe this doesn't
have a file.c because that's all delegated to the lower filesystems,
but still.. Just one file?
Yeah, yeah, we have those horrible drivers that have 10k+ files, and
there are certainly filesystems with much bigger files, but I'd still
wish for more structure. You've got a whole subdirectory of your own.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists