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

[Thomas Petazzoni]

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