udev in kernel source?

udev in kernel source?

[Martin Steigerwald]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]


Hi!

Would that qualify as a reason to put it there and have make-kpkg / make 
deb / make rpm spit out a udev package as well?

shambhala:/var/log> grep -i deprecated syslog | grep udev
Oct 25 09:41:22 shambhala udevd[21078]: udev: missing sysfs features; 
please update the kernel or disable the kernel's CONFIG_SYSFS_DEPRECATED 
option; udev may fail to work correctly                                                            
Oct 25 09:41:37 shambhala kernel: <3>udev: missing sysfs features; please 
update the kernel or disable the kernel's CONFIG_SYSFS_DEPRECATED option; 
udev may fail to work correctly
Oct 25 13:35:10 shambhala kernel: <3>udev: missing sysfs features; please 
update the kernel or disable the kernel's CONFIG_SYSFS_DEPRECATED option; 
udev may fail to work correctly

It seems that nothing critical is not working, but I only found this by 
closely watching the boot process at all.

Granted, for a long time I did not see any udev/kernel version mismatch or 
configuration option mismatch issues, but back in udev early days I were 
hit several times by those annoyances.

Ironically I was about to disable CONFIG_SYSFS_DEPRECATED when it was 
introduced, but then HAL didn't work.

There should be an easy way to figure out whether kernel and deeply related 
userspace tools are matching each other.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: udev in kernel source?

[Frans Pop]

Martin Steigerwald wrote:
> Would that qualify as a reason to put it there and have make-kpkg / make
> deb / make rpm spit out a udev package as well?

How would that help?

It will result in udev more frequently being incompatible with user space. 
It also will increase the chance of failure if you switch between older 
and newer kernel versions.

IMO udev should primarily ensure compatibility with user space. The kernel 
should provide sufficient backwards compatibility to support older udev 
versions.

Sure, there will be cut-off points (one of which you seem to have hit 
here), but in general it's a lot easier to ensure a kernel is compatible 
with your current version of udev than ensuring random upstream versions 
of udev are compatible with your userland (especially if you're running 
the stable version of a distro).

Just my take on this issue.

Cheers,
FJP

Re: udev in kernel source?

[Martin Steigerwald]

[-- Attachment #1: Type: Text/Plain, Size: 1809 bytes --]

Am Sonntag 25 Oktober 2009 schrieb Frans Pop:
> Martin Steigerwald wrote:
> > Would that qualify as a reason to put it there and have make-kpkg /
> > make deb / make rpm spit out a udev package as well?
> 
> How would that help?

That udev and kernel match each other. But you are right, rest of 
userspace that uses udev might not necessarily match.

And there is another issue: AFAIK distributors handle at least parts of 
the udev configuration including rules.

Well other solution would be to guarentee that SYSFS_DEPRECATED works 
correctly in udev until it will be deprecated and remove in kernel source. 
But then you suggest it the other way around:

> Sure, there will be cut-off points (one of which you seem to have hit
> here), but in general it's a lot easier to ensure a kernel is
>  compatible with your current version of udev than ensuring random
>  upstream versions of udev are compatible with your userland
>  (especially if you're running the stable version of a distro).

I am running a mixture of Debian testing/unstable/experimental.

martin@shambhala:~> apt-show-versions | grep udev
libgudev-1.0-0/squeeze uptodate 146-5
libudev0/squeeze uptodate 146-5
udev/squeeze uptodate 146-5

martin@shambhala:~> cat /proc/version
Linux version 2.6.31.5-tp42-toi-3.0.1-04850-g4eddd0d (martin@shambhala) 
(gcc version 4.3.4 (Debian 4.3.4-5) ) #5 PREEMPT Sun Oct 25 18:39:35 CET 
2009

Anyway, I disabled CONFIG_SYSFS_DEPRECATED now.

Maybe its more about the discoverability of such issue: I don't look into 
the boot log / syslog every day. ;)

Hopefully upward incompatible changes in SysFS could be avoided in the 
future.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: udev in kernel source?

[Frans Pop]

(For the kernel mailing lists it is customary to reply-to-all. Due to the 
very high volume on linux-kernel it's otherwise easy to miss replies.)

Martin Steigerwald wrote:
> And there is another issue: AFAIK distributors handle at least parts of
> the udev configuration including rules.

Exactly. Those "plug-in" rules installed by other packages can quite easily 
conflict or overlap with a new version of udev.

For an example of how a udev update can break other programs, see
http://bugs.debian.org/545801.

> Maybe its more about the discoverability of such issue: I don't look into
> the boot log / syslog every day. ;)

Give logcheck a try. I run it on most of my systems, including my laptop.
 
> Hopefully upward incompatible changes in SysFS could be avoided in the
> future.

I wouldn't want to bet on that ;-)

Cheers,
FJP

Re: udev in kernel source?

[Ben Nizette]

On Sun, 2009-10-25 at 18:33 +0100, Martin Steigerwald wrote:

> There should be an easy way to figure out whether kernel and deeply related 
> userspace tools are matching each other.

There are more tools than just udev which fail to work on various kernel
configurations and versions, though granted udev might be one of the
most "deeply related" ones.  Shipping a matching set isn't the kernel's
job, that's the point of formal distributions :-).  Maybe your real beef
is with udev documentation which should give you info regarding what
udev/kernel pairings should work?

	--Ben.