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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux