linux-kernel - Re: [PATCH 2/2] sound: make OSS device number claiming optional

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <s5h63d2o9ds.wl%tiwai@suse.de>
Date:	Wed, 05 Aug 2009 12:14:23 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Colin Guthrie <cguthrie@...driva.org>, Tejun Heo <teheo@...e.de>,
	Greg KH <greg@...ah.com>, Al Viro <viro@....linux.org.uk>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] sound: make OSS device number claiming optional

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
--
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/