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

[Chris Snook]

On Mon, Nov 8, 2010 at 5:22 PM, Charles Manning <manningc2@xxxxxxxxxxxxx> wrote:
> On Monday 08 November 2010 23:24:08 Chris Snook wrote:
>> 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.
>
> This feature was actually requested by one of the major phone players.
> Doing this at mount is more efficient and simpler than doing it in start up
> scripts.

Fine with me.  Faster boot is a perfectly legitimate technical reason.
 (Userspace developers being too lazy to add a line to an initscript
is not.)

>> > 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'm trying to understand where you see that problem coming from.
>
> I agree fully that there were pollution issues when file systems stored their
> configs in fs/kconfig, making this file a mess.
>
> Is it really a problem to have many configs? Consider:
> * All the configs are in fs/yaffs2/Kconfig. They don't clutter a common file.
> * If you're not using yaffs2 then the .config only has  "CONFIG_YAFFS_FS is
> not set". Hardly an overhead to non-yaffs users.
>
> I do agree that there are some configs that should be cleaned up/removed, and
> maybe described better. I'll fix that for the next patch set.

Sorry, I should have scrutinized your Kconfig conditions more
carefully.  You've done it the right way.
--
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/