Le Thu, 31 Jul 2008 16:53:19 +0300, Adrian Bunk <bunk@xxxxxxxxxx> a écrit : > As I've already said in the past I'm personally not a huge fan of > these patches, but if it brings advantages in real-life situations > it's hard to argue against it. Yes, I've seen your points about that kind of patches on linux-embedded, and I understand them. I agree that adding dozens and dozens of configuration items for small features doesn't look like something sustainable on the long run. However, the kernel keeps growing and this isn't sustainable either on the long run for *some* embedded users. So, what should we do ? (That's a real question) Some numbers about a bootable x86 allnoconfig kernel with ELF, ext2 and IDE support : text data bss dec hex filename 1110389 119468 217088 1446945 161421 vmlinux.2.6.26 1134606 118840 212992 1466438 166046 vmlinux.2.6.27-rc1 24217 -628 -4096 19493 4C25 +/- (The only configuration change between the two kernels is CONFIG_FW_LOADER n->y, which pulls drivers/base/firmware_class.o, 3k). > In which use cases can users safely disable this option, and on what > devices have you verified that CONFIG_FILE_LOCKING=n kernels actually > work in practice? As long as they don't use NFS (realistic in many production environments) and that the applications do not rely on advisory locking (flock() and fnctl() F_GETLK and F_SETLK), file locking can be disabled. In practice, I only tested a CONFIG_FILE_LOCKING=n kernel with a basic Busybox under Qemu. Sincerly, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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
