headers
Tom Gundersen | 1 Jan 2012 16:13
Picon
Gravatar

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)

Permalink | Reply | 2 comments |
headers
Kay Sievers | 1 Jan 2012 16:47

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)

Permalink | Reply | 1 comment |
headers
Tom Gundersen | 1 Jan 2012 18:28
Picon
Gravatar

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)

Permalink | Reply | 0 comments |
headers
Mike Frysinger | 2 Jan 2012 22:00
Picon
Favicon
Gravatar

[PATCH] hwdb: drop useless line freeing

getline() takes care of extending the buffer as needed, so no point in
constantly freeing it before every call.

Signed-off-by: Mike Frysinger <vapier <at> gentoo.org>
---
 udev/udev-builtin-hwdb.c |    5 -----
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/udev/udev-builtin-hwdb.c b/udev/udev-builtin-hwdb.c
index e38c6b9..b6af4b6 100644
--- a/udev/udev-builtin-hwdb.c
+++ b/udev/udev-builtin-hwdb.c
 <at>  <at>  -101,11 +101,6  <at>  <at>  static int lookup_vid_pid(const char *database,
 	for (;;) {
 		size_t n;

-		if (line) {
-			free(line);
-			line = NULL;
-		}
-
 		if (getline(&line, &n, f) < 0)
 			break;

--

-- 
1.7.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kay Sievers | 2 Jan 2012 22:49

Re: [PATCH] hwdb: drop useless line freeing

On Mon, Jan 2, 2012 at 22:00, Mike Frysinger <vapier <at> gentoo.org> wrote:
> getline() takes care of extending the buffer as needed, so no point in
> constantly freeing it before every call.

Applied.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Kay Sievers | 11 Jan 2012 22:18

[ANNOUNCE] udev 176

Here comes a new udev version. Thanks to all who have contributed to
this release.

Until ftp.kernel.org is ready, the signed tarball is here:
  http://people.freedesktop.org/~kay/udev/
(This is just a temporary location and the files will be deleted at the moment
ftp.kernel.org is used again)

The tarball can be found here:
 ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/

The development repository can be found here:
 http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary

The ChangeLog can be found here:
 http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog

udev 176
========
The 'devtmpfs' filesystem is required now, udev will not create or delete
device nodes anymore, it only adjusts permissions and ownership of device
nodes and maintains additional symlinks.

A writable /run directory (ususally tmpfs) is required now for a fully
functional udev, there is no longer a fallback to /dev/.udev.

The default 'configure' install locations have changed. Packages for systems
with the historic / vs. /usr split need to be adapted, otherwise udev will
be installed in /usr and not work properly. Example configuration options
to install things the traditional way are in INSTALL.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Greg KH | 11 Jan 2012 22:25
Gravatar

Re: [ANNOUNCE] udev 176

On Wed, Jan 11, 2012 at 10:18:33PM +0100, Kay Sievers wrote:
> All tabs in the source code used for indentation are replaced by spaces now. :)

What?  Why the change?  Are you trying to see if anyone reads these
things? :)

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 3 comments |
headers
Kay Sievers | 11 Jan 2012 22:47

Re: [ANNOUNCE] udev 176

On Wed, Jan 11, 2012 at 22:25, Greg KH <greg <at> kroah.com> wrote:
> On Wed, Jan 11, 2012 at 10:18:33PM +0100, Kay Sievers wrote:
>> All tabs in the source code used for indentation are replaced by spaces now. :)
>
> What?  Why the change?  Are you trying to see if anyone reads these
> things? :)

Yeah, I know now you read it till the end. :)

Why? Because fixed tabs are so pointless, especially mixing tabs and
trailing spaces like the kernel does all over the place. It just makes
not much sense, we just have been used to it. I personally prefer the
non-tab 8-space model now. It's still kernel style and 8 space indent,
just without the weird tabs and no 80 char limit. :)

And we wanted sync everything up with the systemd tree.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Greg KH | 11 Jan 2012 23:07
Gravatar

Re: [ANNOUNCE] udev 176

On Wed, Jan 11, 2012 at 10:47:39PM +0100, Kay Sievers wrote:
> On Wed, Jan 11, 2012 at 22:25, Greg KH <greg <at> kroah.com> wrote:
> > On Wed, Jan 11, 2012 at 10:18:33PM +0100, Kay Sievers wrote:
> >> All tabs in the source code used for indentation are replaced by spaces now. :)
> >
> > What?  Why the change?  Are you trying to see if anyone reads these
> > things? :)
> 
> Yeah, I know now you read it till the end. :)
> 
> Why? Because fixed tabs are so pointless, especially mixing tabs and
> trailing spaces like the kernel does all over the place. It just makes
> not much sense, we just have been used to it. I personally prefer the
> non-tab 8-space model now. It's still kernel style and 8 space indent,
> just without the weird tabs and no 80 char limit. :)
> 
> And we wanted sync everything up with the systemd tree.

Ok, that's a good enough reason alone, at least I know that 'git blame'
will never show any lines of code I ever wrote :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kay Sievers | 11 Jan 2012 23:15

Re: [ANNOUNCE] udev 176

On Wed, Jan 11, 2012 at 23:07, Greg KH <greg <at> kroah.com> wrote:
> On Wed, Jan 11, 2012 at 10:47:39PM +0100, Kay Sievers wrote:
>> On Wed, Jan 11, 2012 at 22:25, Greg KH <greg <at> kroah.com> wrote:
>> > On Wed, Jan 11, 2012 at 10:18:33PM +0100, Kay Sievers wrote:
>> >> All tabs in the source code used for indentation are replaced by spaces now. :)
>> >
>> > What?  Why the change?  Are you trying to see if anyone reads these
>> > things? :)
>>
>> Yeah, I know now you read it till the end. :)
>>
>> Why? Because fixed tabs are so pointless, especially mixing tabs and
>> trailing spaces like the kernel does all over the place. It just makes
>> not much sense, we just have been used to it. I personally prefer the
>> non-tab 8-space model now. It's still kernel style and 8 space indent,
>> just without the weird tabs and no 80 char limit. :)
>>
>> And we wanted sync everything up with the systemd tree.
>
> Ok, that's a good enough reason alone, at least I know that 'git blame'
> will never show any lines of code I ever wrote :)

Oh, I checked, because it was wondering too, git blame nicely ignores
whitespace by default. It all looks the same as before.

You still some original lines in the .c files from the very first
bitkeeper commit. But yeah, we shuffled a lot around over the years.

Kay
--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane