Re: [Alsa-devel] [PATCH] alsa: correct nonsensical sysfs device symlinks

[Greg KH <greg@kroah.com>]

On Thu, Jan 25, 2007 at 03:40:06PM -0500, xiphmont@xiph.org wrote:
> >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.

There is no such thing as a "stable release update" series anymore, you
should know that :)

It's incremental changes, over time, evolving into something new as you
look at the larger picture.

> >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, as this HALD issue is the only thing that I have had reported, and
these patches have been in the -mm tree for quite some time, yes, I
think it is the only thing that has broken.

And yes, we have to have a way to evolve the api over time.  I thought
that given a kernel config option to allow the api to change, if your
userspace has also been updated, is the perfict way.  Then new distro
releases get to take advantage of the new stuff in the kernel, and we
don't break people who cling to Fedora Core 3 while wanting to run new
kernels (hi Andrew...)

In short, it's a bug, I messed up somehow.  And I'm trying to fix it
now, I don't think there's more that I can do, do you?

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

Can you give me the 'tree /sys/class/sound' output?

Does it work properly with old versions of hald now?

Is there anything else left to fix?

thanks,

greg k-h