Tom Gundersen | 1 Jan 16:13 2012
Picon

Minimum kernel version requirement

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 <at> vrfy.org>
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 <at> vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh <at> suse.de>

commit 073120cc28ad9f6003452c8bb9d15a87b1820201
Author: Kay Sievers <kay.sievers <at> vrfy.org>
Date:   Wed Oct 28 19:51:17 2009 +0100

    Driver Core: devtmpfs: use sys_mount()

    Signed-off-by: Kay Sievers <kay.sievers <at> vrfy.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh <at> suse.de>
(Continue reading)

Kay Sievers | 1 Jan 16:47 2012

Re: Minimum kernel version requirement

On Sun, Jan 1, 2012 at 16:13, Tom Gundersen <teg <at> jklm.no> wrote:
> 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?

The bump has no hard dependency. It's devtmpfs in general which got
fixes, the 'devname' static module-load stuff, things like the
in-kernel media-presence polling which udev manages, and some
architectures which have broken syscall implementations which only got
fixed later in .34.

Only the broken syscall stuff will prevent udev from brining up these
old kernels, the rest will only cause some minor details not to work
as expected, but I guess, it's all that can be worked around.

You can only find out yourself, by testing it. I have no good idea
what in detail works and what not, because I never run 2+ years old
kernels on latest userspace. We all only support running new kernels
on old distros and not really the other way around.

I really think old distros should just update the kernel too, it is
much easier than upgrading individual components. Or if that is not
possible, check if the versions in the enterprise distros of these
tools match; these are well supported old versions of these
components. Trying to mix base system tools and hope they work, while
they are years apart from each other, putting then on top of old
(Continue reading)

Tom Gundersen | 1 Jan 18:28 2012
Picon

Re: Minimum kernel version requirement

On Sun, Jan 1, 2012 at 4:47 PM, Kay Sievers <kay.sievers <at> vrfy.org> wrote:
> The bump has no hard dependency. It's devtmpfs in general which got
> fixes, the 'devname' static module-load stuff, things like the
> in-kernel media-presence polling which udev manages, and some
> architectures which have broken syscall implementations which only got
> fixed later in .34.
>
> Only the broken syscall stuff will prevent udev from brining up these
> old kernels, the rest will only cause some minor details not to work
> as expected, but I guess, it's all that can be worked around.

Thanks for the explanation, now I have a better idea. I was aware of
the devname and media-presence stuff, but didn't think that was
relevant since it arrived post-.34 and can be worked around using
custom rules and static nodes. That custom rules might be needed on
old kernel is already clear from the README so that's fine.

If I understand you correctly, I think the README should be reverted to say

"Requirements:
  - Version 2.6.32 of the Linux kernel [...]"

The broken syscalls on pre-.34 kernels on some architectures is
already mentioned explicitly:

"- Some architectures might need a later kernel, that supports accept4(),
    or need to backport the accept4() syscall wiring in the kernel."

I agree that it would be best to drop old kernels, but as long as
people would like to try I guess that's up to them.
(Continue reading)


Gmane