Basically, new distros can disable that option if their userspace can
handle the new structure of sysfs with the symlinks. Users of older
distros with newer kernels can enable the option and (hopefully) not
break anything.
I would like to register a general objection to a change of this size
'hoping to not break anything' in a stable release update (seeing as
how something did break), especially as how no one here who was
maintaining the userspace was apparently even aware it was coming.
So far, it's been working with this being the first
regression reported.
Had it worked properly, it still would have been a regression. This
seems similar to the ALSA copout ("maintaining a kernel ABI is hard!
We require you have a userspace officially approved by us matching
your kernel, and that is your API.") except that in this case, the
userspace maintainence doesn't seem to be as tightly coupled (is hald
the only thing that broke?)
> (Well, it's incomplete like my original patch was in that it only
> changed the device symlinks for controlX and pcmX; the other entries
> still had device entries pointing at card*).
So what does running with this patch make sysfs look like?
A union of old and new, with old taking precedence over new when they
conflict. That is, the [eg] pcmCXdXx entries look like old sysfs, but
the new entries for cardX etc are there too. All device symlinks
point to /sys/device/pciXXXX:XX/XXXX:XX:XX.x entries as before.
Monty
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]