The ghost of sysfs past

By Jonathan Corbet
July 21, 2010

A few years back, it seemed that incompatible sysfs changes created broken systems on a regular basis. Since then, though, things have gotten better, with no reports of broken systems or forced udev upgrades for a while. That improvement is the result of a deliberate effort on the part of the sysfs hackers to stabilize things and to establish best practices for the use of sysfs-exported information. As some linux-next testers are currently finding out, though, the legacy of older sysfs problems has not entirely faded away yet.

The CONFIG_SYSFS_DEPRECATED configuration option exists as one way of mitigating the effects of a major sysfs change. In the early days of sysfs, devices tended to pop up in strange places, including, especially, under /sys/class. In order to bring more consistency to the filesystem, the layout was reorganized to move more device information into /sys/devices, create the /sys/block directory, and more. Needless to say, any such change would be fatal for systems which expected the old layout, so the configuration option was added to restore that old layout when needed.

In 2010, nobody has shipped a distribution which relies on the old layout for some time. So Greg Kroah-Hartman has posted a patch to remove the configuration option and the significant amount of code needed to support it; that patch has also gone into linux-next. Greg notes: "This is no longer needed by any userspace tools, so it's safe to remove."

Except that maybe it's not safe to remove. Andrew Morton quickly reported that his Fedora Core 6 box would not boot without this option. Andrew is well known for running archaic distributions just for the purpose of finding this kind of compatibility issue; one might argue that there probably are not that many other FC6 boxes in use, and even fewer which will be wanting to run 2.6.35 kernels. But, as Dave Airlie noted, RHEL5 boxes will also fail to boot, and there are rather more of those in operation.

Dave's advice was blunt: "Live with your mistakes guys, don't try and bury them." He knows as well as anybody what the cost of living with mistakes is: the graphics ABIs include a few of their own. Mistakes will happen, but, when they become part of the user-space ABI, they can be difficult to get away from. That is why ABI additions tend to come under high levels of scrutiny: once somebody depends on them, they must be supported indefinitely.

Index entries for this article
Kernel	Development model/User-space ABI

The ghost of sysfs past

Posted Jul 22, 2010 3:34 UTC (Thu) by hmh (subscriber, #3838) [Link] (1 responses)

Debian stable also requires CONFIG_SYSFS_DEPRECATED, AFAIK.

The ghost of sysfs past

Posted Jul 22, 2010 14:14 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

Debian 4.0 ('etch') probably does need it, but Debian 5.0 ('lenny', stable) generally does not (though there may be a few packages that do).

The ghost of sysfs past

Posted Jul 22, 2010 6:20 UTC (Thu) by russell (guest, #10458) [Link] (8 responses)

So how many people running RHEL5 are going to take a kernel from anyone other than Redhat? That's what they pay the $ for.

The ghost of sysfs past

Posted Jul 22, 2010 6:45 UTC (Thu) by jengelh (guest, #33263) [Link] (3 responses)

Except that the RHEL kernel is crap for when you want some new things. And there certainly are. Time and again, people pop up in IRC that want, say, TRIM support or Xtables-addons. In reality they are not running RHEL5, but CentOS, and usually so without any support options that would cost them money. And they only do this because some whacky web administrative control panel of sorts exclusively lists RHEL as the only supported Linux OS (not even Fedora or another Enterprise distro like SLES - think of that).

The ghost of sysfs past

Posted Jul 22, 2010 7:49 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

I would note that Cpanel might be whacky but it is extremely popular in the webhosting space resulting in a enormous amount of EL/rebuild deployments. Setting aside that, for various reasons, people do run RHEL with customized kernels including the latest versions and it does not void Red Hat support contracts although people often misunderstand this. Red Hat will ask the customer to check it the problem is reproducible in the kernel that it ships and if it does, Red Hat will want to fix that issue.

The ghost of sysfs past

Posted Jul 31, 2010 2:57 UTC (Sat) by walovaton (guest, #57287) [Link] (1 responses)

Mmmm... really? what if there is no way to reproduce the bug with the official kernel because the application simply won't work on that setup? is there any hope for customers in this situation?.

Likewise, is there any support if I take a RHEL 5 box and update PHP to 5.2 or 5.3, or maybe if I decide to downgrade to PHP 4.3 (the same in RHEL 4) because it's really hard for us to test our huge web system and validate it against the newest version of PHP?.

If there is any link on the Red Hat website that explains this kind of scenarios it would be very handy for me and my company.

The ghost of sysfs past

Posted Jul 31, 2010 3:34 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

You are better off talking to a support technician directly for specific scenarios.

The ghost of sysfs past

Posted Jul 24, 2010 20:15 UTC (Sat) by jcm (subscriber, #18262) [Link] (3 responses)

Obviously, I don't think deliberate incompatibility should be introduced, but I *really* don't think upstream should be worried about breaking an older vendor userland. The vendor is responsible for the kernel on their distribution, and isn't going to offer support for upstream kernels anyway. It seems like a giant non-argument to say that it even matters.

(personal opinion only)

The ghost of sysfs past

Posted Jul 24, 2010 23:50 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (2 responses)

Introducing kernel incompatibilities always results in you reducing the number of people who can test your distribution. Sometimes that's an acceptable tradeoff, but telling people who run Red Hat Enterprise Linux(tm) 5 that it's impossible for them to run a later kernel with their existing userspace sounds like a great way to reduce the number of people who can give you feedback for later releases.

The ghost of sysfs past

Posted Jul 27, 2010 8:33 UTC (Tue) by yodermk (subscriber, #3803) [Link] (1 responses)

RHEL 6 will be out this year, and RHEL users who want later features can use that. Don't hold back progress.

The ghost of sysfs past

Posted Jul 27, 2010 9:43 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

Noone is holding back progress. Things can progress just fine with a bit more backward compatibility. Not everyone will be able to jump to new releases whenever they happen.

The ghost of sysfs past

Posted Jul 22, 2010 9:19 UTC (Thu) by mjthayer (guest, #39183) [Link]

I never quite finished adjusting some code I wrote to fully comply with Greg's advice on how to use sysfs. Does this mean I can forget that and spend the time doing something more productive?

The ghost of sysfs past

Posted Jul 22, 2010 16:44 UTC (Thu) by Tet (guest, #5433) [Link] (1 responses)

one might argue that there probably are not that many other FC6 boxes in use

Well I have one, for a start. Yes, I know it's old. But it works, and does what it needs to do, so I haven't seen to fit to update it. Furthermore, it does what it does better than some of the more modern Fedora releases.

The ghost of sysfs past

Posted Jul 22, 2010 18:04 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]

But you're also not running the latest kernel on it are you? This doesn't really affect you in any way...

Living with your mistakes indefinitely?

Posted Jul 22, 2010 21:36 UTC (Thu) by leoc (guest, #39773) [Link] (2 responses)

How about a periodic (say once every 10 years) divorce from your mistakes? Maintaining backwards compatibility forever seems like a terrible waste of resources for an open source project.

Living with your mistakes indefinitely?

Posted Jul 22, 2010 21:50 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

That period would vary depending on the particular situation. Some will have to live with their mistakes forever. Some can cut it short and have a clean break in a few years.

Living with your mistakes indefinitely?

Posted Jul 23, 2010 10:55 UTC (Fri) by sorpigal (guest, #36106) [Link]

Every 7 years would be more traditional.

The ghost of sysfs past

Posted Jul 23, 2010 15:21 UTC (Fri) by giraffedata (guest, #1954) [Link] (1 responses)

In 2010, nobody has shipped a distribution which relies on the old layout for some time.

This is obvious hyperbole, since there are hundreds of Linux distributions. Especially if you count a custom build.

It's a shame that a kernel developer would want to legitimize only major distributions.

It's even a shame a kernel developer would want to say a distribution is the only legitimate user of sysfs. Just last week, I had a program which is not part of a Linux distribution break because of a more recent reorganization of sysfs. The program is supposed to match up a block device special name with a location in a SAS network for maintenance purposes.

:)

Posted Aug 6, 2010 13:17 UTC (Fri) by gvy (guest, #11981) [Link]

>> nobody has shipped a distribution
> This is obvious hyperbole
Maybe rather an announce of Nobody Linux shipping with CONFIG_SYSFS_DEPRECATED? :)