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