From: Takashi Iwai <tiwai@suse.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Colin Guthrie <cguthrie@mandriva.org>, Tejun Heo <teheo@suse.de>,
Greg KH <greg@kroah.com>, Al Viro <viro@ftp.linux.org.uk>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] sound: make OSS device number claiming optional
Date: Wed, 05 Aug 2009 12:14:23 +0200 [thread overview]
Message-ID: <s5h63d2o9ds.wl%tiwai@suse.de> (raw)
In-Reply-To: <20090805105916.28f84a05@lxorguk.ukuu.org.uk>
At Wed, 5 Aug 2009 10:59:16 +0100,
Alan Cox wrote:
>
> > While I'm not familiar enough with the kernel itself to comment on *how*
> > the patch works, the principle is quite important here.
> >
> > As far as I know most distros enable snd-*-oss module loading via a
> > modprobe trick (e.g. in user space) so the change here shouldn't affect
> > this approach.
> >
> > However, I certainly want to experiment with osspd and while I hope it's
> > going to be a good solution generally, it'll only make sense if the user
> > chooses to use pulseaudio.
> >
> > If the user decided they want to use pure alsa, then they'll have to
> > drop back to using snd-*-oss for that instead.
> >
> > This is all something I'd like to enable without making the user change
> > kernels based on a preference.
>
> As you said "I'd like to experiment"
>
> We don't put everyones random experiments in the kernel or we'd have a
> kernel that had a million unfinished project hacks.
>
> Suppose this doesn't work out - how do we get rid of the new hack,
> someone might by then have decided to depend upon it. More crud, more
> APIs we can't get rid of
>
> More importantly there is an API *in* soundcore for registering sound
> devices in the OSS category. You can use that.
>
> Not only was that interface written precisely to allow the kind of
> sharing in question but it will also let you mix OSS, ALSA *and* your own
> experimental device work at the same time because it hands out minor
> numbers properly.
>
> Given we have an existing proper interface for this I think this hack
> belongs in a private dev tree only. In fact I suspect it belongs in the
> bitbucket and experimental code should be using the proper provided and
> exported interfaces as it will need to if it is ever going to be accepted
> upstream.
>
> NAK
>
> Alan
As far as I understand, the current problem is that ALSA core becomes
dependent when you build with CONFIG_SND_*_OSS config, even if you
load no snd-*-oss modules and use only ALSA-native ones. It's because
the OSS device registration is done through the ALSA snd module.
Thus, loading ALSA modules always results in loading soundcore
module, too.
So... instead of hacking around soundcore stuff, splitting off the OSS
(soundcore) dependency from ALSA snd module could be another solution?
Then soundcore doesn't have to be loaded unless you load snd-*-oss or
any real OSS modules.
One drawback is that this splits to yet another module. Or, maybe it
can be put into somewhere else...
Takashi
next prev parent reply other threads:[~2009-08-05 10:14 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-05 6:35 [PATCH 1/2] chrdev: implement __[un]register_chrdev() Tejun Heo
2009-08-05 6:40 ` [PATCH 2/2] sound: make OSS device number claiming optional Tejun Heo
2009-08-05 9:15 ` Alan Cox
2009-08-05 9:24 ` Colin Guthrie
2009-08-05 9:59 ` Alan Cox
2009-08-05 10:14 ` Takashi Iwai [this message]
2009-08-05 10:26 ` Alan Cox
2009-08-05 10:45 ` Takashi Iwai
2009-08-05 11:15 ` Alan Cox
2009-08-05 11:34 ` Tejun Heo
2009-08-05 12:35 ` Tejun Heo
2009-08-05 13:11 ` Alan Cox
2009-08-05 14:16 ` Tejun Heo
2009-08-05 9:32 ` Tejun Heo
2009-08-05 10:00 ` Alan Cox
2009-08-05 11:27 ` Tejun Heo
2009-08-05 12:48 ` Alan Cox
2009-08-05 14:13 ` Tejun Heo
2009-08-05 14:29 ` Alan Cox
2009-08-05 16:02 ` Tejun Heo
2009-08-05 16:33 ` Alan Cox
2009-08-05 16:38 ` Alan Cox
2009-08-05 16:52 ` Tejun Heo
2009-08-05 17:01 ` Alan Cox
2009-08-06 5:55 ` Tejun Heo
2009-08-05 7:04 ` [PATCH 1/2] chrdev: implement __[un]register_chrdev() Takashi Iwai
2009-08-05 7:11 ` Tejun Heo
2009-08-05 7:20 ` Takashi Iwai
2009-08-05 7:30 ` Tejun Heo
2009-08-05 9:01 ` [PATCH 1/2 UPDATED] " Tejun Heo
2009-08-05 16:16 ` [PATCH 1/2] " Greg KH
2009-08-05 16:30 ` Tejun Heo
2009-08-05 16:49 ` Greg KH
2009-08-05 17:01 ` Tejun Heo
2009-08-05 17:15 ` Greg KH
2009-08-06 5:52 ` Tejun Heo
2009-08-06 8:13 ` Tejun Heo
2009-08-06 19:58 ` Greg KH
2009-08-07 2:34 ` Tejun Heo
2009-08-07 4:05 ` Greg KH
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=s5h63d2o9ds.wl%tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cguthrie@mandriva.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=teheo@suse.de \
--cc=viro@ftp.linux.org.uk \
/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