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. 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? 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. -- Tim ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America ============================= -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
