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

[Charles Manning <manningc2@actrix.gen.nz>]

On Monday 08 November 2010 10:45:32 Chris Snook wrote:
> On Sun, Nov 7, 2010 at 4:59 PM, Charles Manning <manningc2@actrix.gen.nz> 
wrote:
> > On Saturday 06 November 2010 14:50:58 Valdis.Kletnieks@vt.edu wrote:
> >> On Thu, 04 Nov 2010 05:53:16 +1300, cdhmanning@gmail.com said:
> >> > From: Charles Manning <cdhmanning@gmail.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? 

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.

> 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.

> 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.

-- Charles