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? 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
