public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: xiphmont@xiph.org
Cc: Takashi Iwai <tiwai@suse.de>, Pierre Ossman <drzeus@drzeus.cx>,
	fedora-desktop-list@redhat.com, alsa-devel@alsa-project.org,
	jrb@redhat.com, linux-kernel@vger.kernel.org, mclasen@redhat.com,
	Lennart Poettering <lennart@poettering.net>,
	perex@suse.cz
Subject: Re: [Alsa-devel] [PATCH] alsa: correct nonsensical sysfs device symlinks
Date: Thu, 25 Jan 2007 11:49:33 -0800	[thread overview]
Message-ID: <20070125194933.GA27857@kroah.com> (raw)
In-Reply-To: <806dafc20701251051p2750cb34sab88a38282020497@mail.gmail.com>

On Thu, Jan 25, 2007 at 01:51:42PM -0500, xiphmont@xiph.org wrote:
> On 1/25/07, Takashi Iwai <tiwai@suse.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

  reply	other threads:[~2007-01-25 19:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-25  1:50 [PATCH] alsa: correct nonsensical sysfs device symlinks Christopher "Monty" Montgomery
2007-01-25  4:26 ` Greg KH
2007-01-25 14:11   ` Christopher "Monty" Montgomery
2007-01-25 15:15     ` Pierre Ossman
2007-01-25 15:36       ` Christopher "Monty" Montgomery
2007-01-25 15:40         ` Pierre Ossman
2007-01-25 15:57           ` Christopher "Monty" Montgomery
2007-01-25 16:54             ` [Alsa-devel] " Takashi Iwai
2007-01-25 17:03               ` Christopher "Monty" Montgomery
2007-01-25 17:30                 ` xiphmont
2007-01-25 17:47                   ` Takashi Iwai
2007-01-25 18:07                     ` xiphmont
2007-01-25 18:23                       ` Takashi Iwai
2007-01-25 18:34                         ` xiphmont
2007-01-25 18:38                           ` Takashi Iwai
2007-01-25 18:51                             ` xiphmont
2007-01-25 19:49                               ` Greg KH [this message]
2007-01-25 20:40                                 ` xiphmont
2007-01-25 21:59                                   ` Greg KH
2007-01-26 10:53                                     ` xiphmont
2007-01-26 11:40                                       ` Takashi Iwai
2007-01-26 18:04                                         ` Greg KH
2007-01-26 18:25                                           ` Takashi Iwai
2007-01-26 18:31                                             ` xiphmont
2007-01-26 19:06                                             ` Greg KH
2007-01-26 21:58                                               ` xiphmont
2007-01-26 18:03                                     ` xiphmont
2007-01-26 18:42                                       ` Greg KH
2007-01-25 17:48                   ` Christopher "Monty" Montgomery
2007-01-25 11:27 ` Pierre Ossman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070125194933.GA27857@kroah.com \
    --to=greg@kroah.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=drzeus@drzeus.cx \
    --cc=fedora-desktop-list@redhat.com \
    --cc=jrb@redhat.com \
    --cc=lennart@poettering.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mclasen@redhat.com \
    --cc=perex@suse.cz \
    --cc=tiwai@suse.de \
    --cc=xiphmont@xiph.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox