Messages in this thread | | | From | Chris Snook <> | Date | Mon, 8 Nov 2010 06:24:08 -0400 | Subject | Re: [PATCH 1/9] Add yaffs Kconfig and Makefile |
| |
On Sun, Nov 7, 2010 at 6:22 PM, Charles Manning <manningc2@actrix.gen.nz> wrote: > 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.
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |