Re: [patch 2/4] Configure out file locking features

[Adrian Bunk]

On Thu, Jul 31, 2008 at 10:32:20AM -0700, Tim Bird wrote:
> Adrian Bunk wrote:
> > And for embedded systems with which applications is it 100% safe to 
> > disable this option?
> 
> Sony's digital cameras.
> 
> This option *is* disabled in the kernel for (most) Sony digital cameras.
> Those digital cameras have the kernel, busybox, a custom C library,
> and one proprietary application.   The application does not use
> flock() (or AIO, or ethtool or multi-cast)
> 
> These cameras were heavily tested, and are shipping now.  I can't
> make any guarantees for other developers, but those of us who
> are careful about our application development would like the option
> to eliminate completely unused features from the kernel.  (And
> the C library, but that's a different issue.)
> 
> > And don't answer "doesn't use flock()", I want a real-life example of a 
> > device where you could guarantee a developer that disabling this option 
> > in his product would be safe.
> 
> I'm not sure why a guarantee is required that other developers
> use this option safely.  Maybe this is a point of disconnect between
> embedded folks and non-embedded folks.  We're accustomed to making
> tradeoff decisions that only affect our product, and which
> we take full responsibility for testing.

Thanks. That's quite different from Thomas' "In practice, I only tested
a CONFIG_FILE_LOCKING=n kernel with a basic Busybox under Qemu." and
addresses my concerns.

In case I didn't express myself clearly:
I was not interested in guarantees for random developers but in seeing 
some reasonable use case for a real device.

> If warnings or support avoidance for the general population using
> such config options is the issue, I think that David Woodhouse's
> suggestion that such things could taint the kernel is an interesting
> idea. Maybe have we could have an "unsafe-config" taint flag?

A CONFIG_EMBEDDED=y flag?

> I should add that I am sympathetic with the larger issue you raise
> about nibbling at the bottom with patches that only address a
> few KB of the problem, while the size continues to build (to an
> even greater degree) with each release.  My response is that I agree
> with you on the nibbling bit, but probably just at a different
> level of KB savings.
> 
> That is, I presume you'd be OK with something that saved 100K or
> even 20K, but balk at bit at these patches, which save 10k or less.
> My threshold is lower (probably down to about 5K, so these are
> pretty close to the bubble), but even I wouldn't recommend
> applying anything much below that.  We've already started
> considering to drop some linux-tiny patches that just don't save
> enough to warrant continued maintenance.

It's not only about limits, I also have a general dislike for the
"add more config options" approach.

I get your point why it brings advantages in some cases, but if you are 
looking for a cheerleader it won't be me.  ;-)

>  -- Tim

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--
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/