Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1639239 > unrolled thread

future of sounds/oss

Back to article view | Back to linux.kernel

Contents

  future of sounds/oss Christoph Hellwig <hch@lst.de> - 2017-05-11 10:30 +0200
    Re: [alsa-devel] future of sounds/oss Takashi Iwai <tiwai@suse.de> - 2017-05-11 10:50 +0200
      Re: [alsa-devel] future of sounds/oss Christoph Hellwig <hch@lst.de> - 2017-05-11 11:20 +0200
      Re: future of sounds/oss Takashi Sakamoto <o-takashi@sakamocchi.jp> - 2017-05-11 12:10 +0200
        Re: future of sounds/oss Takashi Sakamoto <o-takashi@sakamocchi.jp> - 2017-05-11 12:40 +0200
          Re: future of sounds/oss Takashi Iwai <tiwai@suse.de> - 2017-05-11 14:20 +0200

#1639239 — future of sounds/oss

Ho Jaroslav, hi Takashi,

do you know who still uses the sound/oss drivers and why?  I've
recently been looking into getting rid of set_fs for using
copy_{from,to}_user and friends on kernel pointers, and the sound
code is a big abuser, both ALSA and the legacy OSS code.

But looking at the OSS code it's pretty grotty, and also appears
to be pretty much unmaintained except for global cleanups.  Is there
any chance we could look into getting rid of it over the next few
merge windows or are there people that rely on it?

[toc] | [next] | [standalone]

#1639253 — Re: [alsa-devel] future of sounds/oss

On Thu, 11 May 2017 10:21:33 +0200,
Christoph Hellwig wrote:
> 
> Ho Jaroslav, hi Takashi,
> 
> do you know who still uses the sound/oss drivers and why?  I've
> recently been looking into getting rid of set_fs for using
> copy_{from,to}_user and friends on kernel pointers, and the sound
> code is a big abuser, both ALSA and the legacy OSS code.

Yeah, I also started looking at it after reading the LWN article.
The removal of set_fs() in ALSA part was already finished, and I'm
currently brushing up the patches.  It'll be in 4.13 at latest.

But the set_fs() usage in OSS code is hard to get rid of, due to the
in-kernel ioctl calls, and I really don't want to touch such dusty
codes, either.  So I wanted to post the very same question, but you
were faster :)

> But looking at the OSS code it's pretty grotty, and also appears
> to be pretty much unmaintained except for global cleanups.  Is there
> any chance we could look into getting rid of it over the next few
> merge windows or are there people that rely on it?

I don't think there are any active users.  The only slight concern is
that there are a few ancient devices that are supported only by some
OSS drivers.  But these are over decades, and very unlikely alive.

That said, I'd love to drop that legacy stuff; or maybe as a
soft-landing, begin with disabling the build of sound/oss in Kconfig.

The latter can be done even for 4.12, if Linus doesn't mind.


thanks,

Takashi

[toc] | [prev] | [next] | [standalone]

#1639267 — Re: [alsa-devel] future of sounds/oss

On Thu, May 11, 2017 at 10:46:47AM +0200, Takashi Iwai wrote:
> Yeah, I also started looking at it after reading the LWN article.
> The removal of set_fs() in ALSA part was already finished, and I'm
> currently brushing up the patches.  It'll be in 4.13 at latest.

Great!

> That said, I'd love to drop that legacy stuff; or maybe as a
> soft-landing, begin with disabling the build of sound/oss in Kconfig.
> 
> The latter can be done even for 4.12, if Linus doesn't mind.

I'd be absolutely in favor of trying that and seeing if anyone
screams.

[toc] | [prev] | [next] | [standalone]

#1639282

Hi,

On May 11 2017 17:46, Takashi Iwai wrote:
> On Thu, 11 May 2017 10:21:33 +0200,
> Christoph Hellwig wrote:
>>
>> Ho Jaroslav, hi Takashi,
>>
>> do you know who still uses the sound/oss drivers and why?  I've
>> recently been looking into getting rid of set_fs for using
>> copy_{from,to}_user and friends on kernel pointers, and the sound
>> code is a big abuser, both ALSA and the legacy OSS code.
>
> Yeah, I also started looking at it after reading the LWN article.
> The removal of set_fs() in ALSA part was already finished, and I'm
> currently brushing up the patches.  It'll be in 4.13 at latest.

Eventually, I'm also working for it[1]. I'm willing to review your 
changes, so please add me into CC list when you post patches.

Instead, In this development cycle, I'll post my patches for tracepoints 
for PCM parameter handling and misc refactoring[2]. (I've already done 
most of the work.)

> But the set_fs() usage in OSS code is hard to get rid of, due to the
> in-kernel ioctl calls, and I really don't want to touch such dusty
> codes, either.  So I wanted to post the very same question, but you
> were faster :)
>
>> But looking at the OSS code it's pretty grotty, and also appears
>> to be pretty much unmaintained except for global cleanups.  Is there
>> any chance we could look into getting rid of it over the next few
>> merge windows or are there people that rely on it?
>
> I don't think there are any active users.  The only slight concern is
> that there are a few ancient devices that are supported only by some
> OSS drivers.  But these are over decades, and very unlikely alive.
>
> That said, I'd love to drop that legacy stuff; or maybe as a
> soft-landing, begin with disabling the build of sound/oss in Kconfig.
>
> The latter can be done even for 4.12, if Linus doesn't mind.

I think we don't need to care of drivers implemented with Open Sound 
System. In my understanding, stuffs in 'sound/core/oss/*' give Open 
Sound System compatibility layer for Open Sound System applications. In 
short, it gives a way for the applications to use drivers in ALSA by 
Open Sound System interfaces. Even if this layer is missing, the 
applications are still available with Open Sound System Proxy Daemon[3] 
with FUSE/CURE assistances. I believe we can get rid of them without any 
actual disadvantages.

[1] https://github.com/takaswie/sound/tree/topic/segment-in-pcm
[2] https://github.com/takaswie/sound/tree/topic/trace+refactor
[3] https://github.com/libfuse/osspd


Regards

Takashi Sakamoto

[toc] | [prev] | [next] | [standalone]

#1639297

On May 11 2017 19:01, Takashi Sakamoto wrote:
>> But the set_fs() usage in OSS code is hard to get rid of, due to the
>> in-kernel ioctl calls, and I really don't want to touch such dusty
>> codes, either.  So I wanted to post the very same question, but you
>> were faster :)
>>
>>> But looking at the OSS code it's pretty grotty, and also appears
>>> to be pretty much unmaintained except for global cleanups.  Is there
>>> any chance we could look into getting rid of it over the next few
>>> merge windows or are there people that rely on it?
>>
>> I don't think there are any active users.  The only slight concern is
>> that there are a few ancient devices that are supported only by some
>> OSS drivers.  But these are over decades, and very unlikely alive.
>>
>> That said, I'd love to drop that legacy stuff; or maybe as a
>> soft-landing, begin with disabling the build of sound/oss in Kconfig.
>>
>> The latter can be done even for 4.12, if Linus doesn't mind.
>
> I think we don't need to care of drivers implemented with Open Sound
> System. In my understanding, stuffs in 'sound/core/oss/*' give Open
> Sound System compatibility layer for Open Sound System applications. In
> short, it gives a way for the applications to use drivers in ALSA by
> Open Sound System interfaces. Even if this layer is missing, the
> applications are still available with Open Sound System Proxy Daemon[3]
> with FUSE/CURE assistances. I believe we can get rid of them without any
> actual disadvantages.

Oops. I misunderstand to have discussion about stuffs in 
'sound/core/oss/*', because the compatibility layer also includes abuses 
of set_fs() and I'm interested in it today...

For stuffs in 'sound/oss', we should certainly have care of points which 
Iwai-san mentioned. If we get rid of it, we can also apply diet to 
'soundcore' module which gives 'sound' class but include some helper 
functions just for Open Sound System drivers.


Regards

Takashi Sakamoto

[toc] | [prev] | [next] | [standalone]

#1639355

On Thu, 11 May 2017 12:36:47 +0200,
Takashi Sakamoto wrote:
> 
> Oops. I misunderstand to have discussion about stuffs in
> 'sound/core/oss/*', because the compatibility layer also includes
> abuses of set_fs() and I'm interested in it today...

Yes, the stuff in sound/core/oss required an intensive surgery to get
rid of set_fs().  But this resulted in a good cleanup of the
duplicated copy/silence callbacks in the end.

> For stuffs in 'sound/oss', we should certainly have care of points
> which Iwai-san mentioned. If we get rid of it, we can also apply diet
> to 'soundcore' module which gives 'sound' class but include some
> helper functions just for Open Sound System drivers.

Right, that's low-hanging fruits we can take once after confirming the
removal of OSS drivers.  The soundcore module can be removed and
integrated into the ALSA OSS emulation stuff, for example.


thanks,

Takashi

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web