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

Hello, Alan.

Alan Cox wrote:
>> The only problem here is the now obsolete hackish way OSS module
>> auto-loading is handled.  CUSE is being a regular chardev citizen.
> 
> "obsolete hackish". It's the same mechanism used by just about every
> other driver that multiplexes. Doesn't seem obsolete to me. You are
> expected to register subdrivers of most specialist interfaces through
> that interface. You use misc_register, video_register_device etc.

Subsystem registration isn't hackish or obsolete but claiming all
minor devices to use custom module alises is at best obsolete.  There
just is no reason to do that.

> Providing you do so it all works nicely.
> 
> The OSS device major is owned by OSS (soundcore). If you want to use it
> your driver should use the interfaces provided by soundcore. Ditto any
> other similar interface.

None of this would be a problem if OSS doesn't claim minors it doesn't
have actual device for and as I said multiple times there is no
benefit in doing that, not anymore and the only reason to keep that
around is to maintain backward compatibility for a mostly unused and
easy to work around feature.

>> Given the situation, I sure can add hacks to CUSE so that it doesn't
>> do regular chardev thing but does OSS specific stuff if OSS major is
>> detected.  To me, this would be much painful exercise in spreading the
>> hack.
> 
> And it can then be a good citizen and share the resource. CUSE needs to
> do the same for video/misc/framebuffer/tty/usb/etc so this is a general
> pattern it needs to handle. In short cuse needs to grow this ability
> anyway if it wants to be support these sorts of device.

The sharing and mixing and matching can happen very gracefully at
chrdev level.  Does it make sense to drag it down to each subsystem
level just to use custom module alises?  Not at all to me.  The same
goes for video or whatever.  There is no reason to claim unused device
numbers anymore and as long as that holds everyone is good citizen at
the chrdev region.  That's _much_ cleaner.

>> I don't see much reason to go through feature removal process for the
>> now obsolete OSS-specific module requesting feature.  Allowing distros
>> to make the switch as they see fit and letting the code wither away is
>> the least painful way.
> 
> You appear to be self contradictory here. Either
> 
> - OSS is irrelevant in which case we don't need the CUSE stuff either
> - OSS is relevant in which case we shouldn't break it

What's broken?  Module aliases?  The whole point of the patch is to
let people keep the module alises while allowing distros which wish to
try or switch to different mechanism to do so.

> A few old old games still use OSS, are proprietary apps and have never
> been re-released. Some of them also do irritiating to emulate things like
> use mmap. Flash at least appears to have finally gotten the message.

I like backward compatibility and think it's relevant but its
relevance is much lower than current stuff and ever diminishing.  Plus
the current in-kernel emulation has annoying limitations which can be
alleviated by userland implementation.  So,

 * OSS compatibility as seen from userland apps : relevant

 * doing everything right by sound_core.c which basically is only used
   by in-kernel emulation : not so much

Thanks.

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