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