Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits still need this? Is work being done to eliminate the need for this?
-Louis
Louis E Garcia II schrieb:
Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits still need this? Is work being done to eliminate the need for this?
-Louis
You could also ask x86 core maintainers. They also do set it in config-generic. :-) I guess no pkg in core/extras needs it, but maybe RH folks have it included for the wild? Who knows what proggies people out there want to run on their machines.... :-)
Best, Oliver
PS: [oliver@pils ~/cvs/Fedora/core/devel/kernel/configs]$ grep CONFIG_SYSFS_DEPRECATED *config* config-generic:CONFIG_SYSFS_DEPRECATED=y
Oliver Falk schrieb:
Louis E Garcia II schrieb:
Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits still need this? Is work being done to eliminate the need for this?
You could also ask x86 core maintainers. [...]
Or the changelog:
$ rpm -q kernel-2.6.20-1.2990.fc7 --changelog | grep -i -A 1 -B 1 DEPRECATED * Fr Jan 26 2007 Bill Nottingham notting@redhat.com - turn on CONFIG_SYSFS_DEPRECATED so that things actually work. *sigh*
Not that this information in this case actually helps what things didn't work without it. ;-)
CU thl
Thorsten Leemhuis schrieb:
Oliver Falk schrieb:
Louis E Garcia II schrieb:
Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits still need this? Is work being done to eliminate the need for this?
You could also ask x86 core maintainers. [...]
Or the changelog:
Good point. Should have grep-ed in spec also :-)
-of
Le samedi 17 mars 2007 à 21:10 -0400, Louis E Garcia II a écrit :
Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits still need this? Is work being done to eliminate the need for this?
Run a kernel without this option, test, report problems
IMHO if we wanted we could target F7 without this. So far I've only found lm_sensors broken because of class changes, and upstream promised me a fixed version last week (running with a local patch I tested for them now)
On Sat, 2007-03-17 at 21:10 -0400, Louis E Garcia II wrote:
Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits still need this? Is work being done to eliminate the need for this?
Hopefully. It's causing oopses. We should ideally have bugs filed for anything in userspace which needs it.
On Sun, 2007-03-18 at 15:40 +0000, David Woodhouse wrote:
On Sat, 2007-03-17 at 21:10 -0400, Louis E Garcia II wrote:
Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits still need this? Is work being done to eliminate the need for this?
Hopefully. It's causing oopses. We should ideally have bugs filed for anything in userspace which needs it.
See the message on lkml and linux-wireless with the subject:
Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
It actually has nothing to do with NetworkManager, but the problem is that gregkh's patch broke HAL in ways that only an as-then unreleased version of HAL could cope with (and possibly other stuff).
Root cause was that the patch gregkh landed was faulty. See his mail with this subject and the date of "Tue, 6 Mar 2007 12:05:37 -0800 (15:05 EST)". The patch removed the 'device' link from /sys/class/net/XXX/ directories, which means you simply cannot match up the class device with the hardware it actually is, which is wrong & bad.
Dan
----- Can you try the patch below? And enable CONFIG_SYSFS_DEPRECATED. It should cause HAL to see the network devices again, as the symlink is now back (it shouldn't have gone away, that was my fault...)
I tried this with HAL 0.5.7, which is pretty old, and hal-device-manager shows my network devices properly.
thanks for your patience,
greg k-h -----
David Woodhouse (dwmw2@infradead.org) said:
Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits still need this? Is work being done to eliminate the need for this?
Hopefully. It's causing oopses. We should ideally have bugs filed for anything in userspace which needs it.
It's causing oopses, so we should fix userspace because the kernel is busted?
It's known what needs it, it's unlikely to be fixed before F7.
Bill
On Mon, 2007-03-19 at 10:53 -0400, Bill Nottingham wrote:
David Woodhouse (dwmw2@infradead.org) said:
Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits still need this? Is work being done to eliminate the need for this?
Hopefully. It's causing oopses. We should ideally have bugs filed for anything in userspace which needs it.
It's causing oopses, so we should fix userspace because the kernel is busted?
Because a _deprecated_ feature in the kernel is busted, you mean?
The answer would be 'maybe'. I can't say; I don't know what needs it. I have a crappy workaround which disables _some_ of what CONFIG_SYSFS_DEPRECATED does, but I don't know if that's the bit which this obsolete userspace stuff is using.
It's known what needs it, it's unlikely to be fixed before F7.
Bug numbers or more details? The workaround of which I speak is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227893#c9
David Woodhouse (dwmw2@infradead.org) said:
Because a _deprecated_ feature in the kernel is busted, you mean?
Yes. Kernel oopses -> kernel broken.
The answer would be 'maybe'. I can't say; I don't know what needs it.
The installer.
It's known what needs it, it's unlikely to be fixed before F7.
Bug numbers or more details? The workaround of which I speak is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227893#c9
It's 'port the installer to use hal & udev', there's not a bug number, probably because it's generally understood that it's not happening right now.
Bill
On Mon, 2007-03-19 at 11:13 -0400, Bill Nottingham wrote:
David Woodhouse (dwmw2@infradead.org) said:
Because a _deprecated_ feature in the kernel is busted, you mean?
Yes. Kernel oopses -> kernel broken.
And CONFIG_SYSFS_DEPRECATED=n --> kernel no longer oopsing. It's probably still buggy, but at least the bug is hidden.
The answer would be 'maybe'. I can't say; I don't know what needs it.
The installer.
It's known what needs it, it's unlikely to be fixed before F7.
Bug numbers or more details? The workaround of which I speak is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227893#c9
It's 'port the installer to use hal & udev', there's not a bug number, probably because it's generally understood that it's not happening right now.
OK, so since the above workaround only removes some environment variables which were being passed to the hotplug/udev script, it shouldn't matter that they're now missing, because the installer wasn't using them anyway?
It's not a very nice fix, and we still have a kernel bug. But at least it's a possibility.
David Woodhouse (dwmw2@infradead.org) said:
It's 'port the installer to use hal & udev', there's not a bug number, probably because it's generally understood that it's not happening right now.
OK, so since the above workaround only removes some environment variables which were being passed to the hotplug/udev script, it shouldn't matter that they're now missing, because the installer wasn't using them anyway?
!CONFIG_SYSFS_DEPRECATED changes the sysfs layout significantly. (Hey, when they say the kernel doesn't have a fixed ABI, they aren't kidding.)
This breaks the hardware detection logic used by the installer in about five or six different places.
Bill
On Mon, 2007-03-19 at 11:28 -0400, Bill Nottingham wrote:
OK, so since the above workaround only removes some environment variables which were being passed to the hotplug/udev script, it shouldn't matter that they're now missing, because the installer wasn't using them anyway?
!CONFIG_SYSFS_DEPRECATED changes the sysfs layout significantly. (Hey, when they say the kernel doesn't have a fixed ABI, they aren't kidding.)
This breaks the hardware detection logic used by the installer in about five or six different places.
But changes to environment variables in the hotplug script invocations shouldn't hurt, right?
David Woodhouse (dwmw2@infradead.org) said:
!CONFIG_SYSFS_DEPRECATED changes the sysfs layout significantly. (Hey, when they say the kernel doesn't have a fixed ABI, they aren't kidding.)
This breaks the hardware detection logic used by the installer in about five or six different places.
But changes to environment variables in the hotplug script invocations shouldn't hurt, right?
No, but that's not the reason we have DEPRECATED on.
Bill
On Mon, 2007-03-19 at 11:56 -0400, Bill Nottingham wrote:
But changes to environment variables in the hotplug script >
invocations shouldn't hurt, right?
No, but that's not the reason we have DEPRECATED on.
OK, thanks for the information. I've committed a crappy hack which disables those extra environment variables (the ones which CONFIG_SYSFS_DEPRECATED enables). It's those which were crashing the kernel.
It's not the _correct_ fix, because the crash is just a _symptom_ of the fact that somewhere in that sysfs mess we have a pointer to freed memory. But at least it prevents the kernel from crashing, which is probably a good thing in the short term.
Once I've finished bringing up the PlayStation 3, I'll have time to go back and investigate all the non-ppc-specific bugs I've been finding in my rawhide testing, including this one.
Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits still need this? Is work being done to eliminate the need for this?
Hopefully. It's causing oopses. We should ideally have bugs filed for anything in userspace which needs it.
See the message on lkml and linux-wireless with the subject:
Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
It actually has nothing to do with NetworkManager, but the problem is that gregkh's patch broke HAL in ways that only an as-then unreleased version of HAL could cope with (and possibly other stuff).
Root cause was that the patch gregkh landed was faulty. See his mail with this subject and the date of "Tue, 6 Mar 2007 12:05:37 -0800 (15:05 EST)". The patch removed the 'device' link from /sys/class/net/XXX/ directories, which means you simply cannot match up the class device with the hardware it actually is, which is wrong & bad.
Dan
So this might be fixed in 2.6.21? Might be fun to unset this for one fedora kernel release to see what happens. Bill? Dave?
-Louis
-
Bill Nottingham -
Dan Williams -
David Woodhouse -
Louis Garcia -
Nicolas Mailhot -
Oliver Falk -
Thorsten Leemhuis