[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070125194933.GA27857@kroah.com>
Date: Thu, 25 Jan 2007 11:49:33 -0800
From: Greg KH <greg@...ah.com>
To: xiphmont@...h.org
Cc: Takashi Iwai <tiwai@...e.de>, Pierre Ossman <drzeus@...eus.cx>,
fedora-desktop-list@...hat.com, alsa-devel@...a-project.org,
jrb@...hat.com, linux-kernel@...r.kernel.org, mclasen@...hat.com,
Lennart Poettering <lennart@...ttering.net>, perex@...e.cz
Subject: Re: [Alsa-devel] [PATCH] alsa: correct nonsensical sysfs device symlinks
On Thu, Jan 25, 2007 at 01:51:42PM -0500, xiphmont@...h.org wrote:
> On 1/25/07, Takashi Iwai <tiwai@...e.de> wrote:
>
> >> [This does beg the question: Does the benefit of this complete
> >> restructuring in a subminor release of an allegedly stable kernel
> >> outweigh the fact that it breaks all audio for any user running a
> >> gnome desktop?]
> >
> >Well, that's not me who introduced that ;)
>
> Consider it addressed to those responsible.
Which would be me. :)
And no, I don't want to break anything, hence that config option. If
it's enabled, sysfs should look just like before. But it looks like we
messed up somewhere and we need to fix it
> >Also, avoid creating card* instance. It makes no sense in that case.
>
> Well, the 'new' entries don't interfere with old-- and we inevitably
> are going to end up with a situation where some software can only read
> the 'new' entries and some software can only read the 'old', otherwise
> why offer compatability at all? I interpreted the
> CONFIG_SYSFS_DEPRECATED option to mean 'also offer the deprecated
> entries in addition to the new structure', otherwise the name should
> be CONFIG_SYSFS_OLDSTYLE or some such to imply they're mutually
> exclusive....
The name of the config option doesn't really matter as much as the help
text of the option does. Does reading that help out more?
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. So far, it's been working with this being the first
regression reported.
> >(So... what's wrong with my patch?)
>
> As it turns out, nothing (I made some error somewhere initially when
> testing it).
> Apologies if I wasn't clear.
>
> (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?
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists