[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikZ19E3EXQ+DPKvWRXYZdmpin0Z_2QAnyFoFm6i@mail.gmail.com>
Date: Sun, 7 Nov 2010 17:45:32 -0400
From: Chris Snook <chris.snook@...il.com>
To: Charles Manning <manningc2@...rix.gen.nz>
Cc: Valdis.Kletnieks@...edu, cdhmanning@...il.com,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 1/9] Add yaffs Kconfig and Makefile
On Sun, Nov 7, 2010 at 4:59 PM, Charles Manning <manningc2@...rix.gen.nz> wrote:
> On Saturday 06 November 2010 14:50:58 Valdis.Kletnieks@...edu wrote:
>> On Thu, 04 Nov 2010 05:53:16 +1300, cdhmanning@...il.com said:
>> > From: Charles Manning <cdhmanning@...il.com>
>> > +config YAFFS_EMPTY_LOST_AND_FOUND
>> > + bool "Empty lost and found on boot"
>> > + depends on YAFFS_FS
>> > + default n
>> > + help
>> > + If this is enabled then the contents of lost and found is
>> > + automatically dumped at mount.
>>
>> Wow.. Just.. wow.
>
> What does that mean?
>
>> Under what use case is this a good idea for a config
>> option as opposed to a mount option?
>
> It is both.
>
> Providing a config option provides the system integrator with flexibility in
> how they set things up.
Does the config option override the mount option, or does the mount
option override the config option? No matter what you do, someone
will be surprised, and that's a bad thing. I'm having difficulty
imagining a circumstance when you couldn't simply do this in userspace
immediately after mount, but if for whatever reason you need
mount+dump to be an atomic operation, it *really* should not be
polluting the kernel configuration.
There are a whole bunch of options in here that appear to be intended
to support various different stages of development. Is there some
reason why you can't call that mess of permutations YAFFS1, and merge
a clean YAFFS2 patch that doesn't depend on it? I know that you're
trying to support multiple operating systems with the same codebase,
but once your code is merged it will get patched by other people
making kernel-wide changes, and testing (or even eyeballing) all those
permutations will be far outside the realm of feasibility.
-- Chris
--
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