Hi guys,
In Arch (and, as far as I understand, also in Debian) we are
interested in making the latest udev work with the latest LTS kernel
(currently 2.6.32.51). However, the minimum requirement in udev's
README is currently listed as 2.6.34 (bumped from .32 last year). On
IRC Kay mentioned that the reason for this is some bugs in devtmpfs in
2.6.32.y. Could anyone provide any more details on what fixes are
missing?
As far as I can tell, the devtmpfs related patches included in .34.y
and not in .32.y are:
commit 015bf43b07158668c2f38af463939afcc6d19403
Author: Kay Sievers <kay.sievers@xxxxxxxx>
Date: Wed Oct 28 19:51:26 2009 +0100
Driver Core: devtmpfs: do not remove non-kernel-created directories
Signed-off-by: Kay Sievers <kay.sievers@xxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
commit 073120cc28ad9f6003452c8bb9d15a87b1820201
Author: Kay Sievers <kay.sievers@xxxxxxxx>
Date: Wed Oct 28 19:51:17 2009 +0100
Driver Core: devtmpfs: use sys_mount()
Signed-off-by: Kay Sievers <kay.sievers@xxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
commit ed413ae6e7813d3227eef43bc6d84ca4f4fe6b21
Author: Kay Sievers <kay.sievers@xxxxxxxx>
Date: Wed Oct 28 19:51:06 2009 +0100
Driver core: devtmpfs: prevent concurrent subdirectory creation and removal
Signed-off-by: Kay Sievers <kay.sievers@xxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
commit 0092699643703aefca6af0aa758a73f1624d53be
Author: Kay Sievers <kay.sievers@xxxxxxxx>
Date: Wed Oct 28 19:50:57 2009 +0100
Driver Core: devtmpfs: ignore umask while setting file mode
Signed-off-by: Kay Sievers <kay.sievers@xxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
Are there any reasons why the relevant fixes are not in 2.6.32.y? Are
there any other reasons to keep the minimum requirement at .34?
I'd be happy to push some patches to Greg for inclusion in LTS if that
is all that is missing for udev to support .32.
Cheers,
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
