Re: [PATCH 1/9] Add yaffs Kconfig and Makefile

[Chris Snook]

On Sun, Nov 7, 2010 at 6:22 PM, Charles Manning <manningc2@xxxxxxxxxxxxx> wrote:
> On Monday 08 November 2010 10:45:32 Chris Snook wrote:
>> On Sun, Nov 7, 2010 at 4:59 PM, Charles Manning <manningc2@xxxxxxxxxxxxx>
> wrote:
>> > On Saturday 06 November 2010 14:50:58 Valdis.Kletnieks@xxxxxx wrote:
>> >> On Thu, 04 Nov 2010 05:53:16 +1300, cdhmanning@xxxxxxxxx said:
>> >> > From: Charles Manning <cdhmanning@xxxxxxxxx>
>> >> > +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?
>
> Config sets up a default, mount options can override those.
>
>> 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,
>
> Sure it could be done in user space, but it is easier to handle this in the
> mount.

We generally try to do things in userspace unless there's a clear
advantage to doing them in the kernel.  This behavior creates an
unnecessary special case for file deletion.

>> it *really* should not be
>> polluting the kernel configuration.
>
> Perhaps just make it a mount option.
>
>>
>> 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?
>
> You seem to misunderstand what YAFFS1 and YAFFS2 are.
>
> Your point is well taken though. Many of these options are "tweaks" that could
> be dropped form Kconfig and only offered as mount options.

Thanks.  I know we've allowed a lot of stupid Kconfig options in the
past, but Kconfig bloat is getting to be a real problem.

>> 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.
>
> To be clear: none of the Kconfig options relate to other OS support.
>
> It is my intention to continue to support other OSs and backporting + new
> features though yaffs.net and patch those into mainstream. While some future
> changes might make this infeasible, I'll cross that bridge when we get to it.
> I'm not going to give up yet.

You're a braver man than I, but as long as that doesn't directly
impact non-YAFFS users/developers, I don't mind.

-- Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/