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
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
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
(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
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.