From: Tejun Heo <teheo@suse.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg KH <greg@kroah.com>, Al Viro <viro@ftp.linux.org.uk>,
Takashi Iwai <tiwai@suse.de>,
Linux Kernel <linux-kernel@vger.kernel.org>,
cguthrie@mandriva.org
Subject: Re: [PATCH 2/2] sound: make OSS device number claiming optional
Date: Thu, 06 Aug 2009 01:02:50 +0900 [thread overview]
Message-ID: <4A79AD2A.4060308@suse.de> (raw)
In-Reply-To: <20090805152942.42e785f3@lxorguk.ukuu.org.uk>
Hello, Alan.
Alan Cox wrote:
> I would suggest you read the code for the others. OSS is probably the
> easy one to kill but the others create objects for platform wide sysfs
> files and the like (as indeed OSS once did for a proc file) so in the
> general case CUSE needs to work through them.
I don't think it's wise for CUSE to try to emulate all those. CUSE
provides emulation for a character device file and that's it. It's a
building block not a complete solution. In many cases information
provided via sysfs or proc doesn't matter to much for individual apps
and there's no reason to try to emulate them. For other cases, those
nodes would need to be emulated using other building blocks - tmpfs or
fuse overlay mount maybe.
>> * 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
>
> So instead of weird config magic why not send both messages.
It's weird but simple and the alternative behavior of only acquiring
existent devices shouldn't hurt anyone who's using anything remotely
modern. The only thing that changes is the module alias kernel
requests after all. Oh well...
> Initially soundcore can generate both requests for sound-slot-foo
> and also fake up its own char requests. It's easy to do, it doesn't
> put any code into the kernel we'll be stuck with for years with
> weird config options. It doesn't require the user choose a magic
> kernel option - it just works.
>
> It's not much code either - just another request call in soundcore_open -
> one line extra to write, a year to wait (4 releases ?) and then the old
> stuff can go away, ALSA can then avoid soundcore and soundcore can vanish.
>
> Much cleaner, and I believe one line of code ?
Hmm... the problem is that the old stuff claims the whole chrdev
region. I was thinking about adding support for alternative module
alises at the chrdev layer if this is that essential and changing
sound_core to claim only the devices which actually exist. That way
we can continue to use the same module aliases and allo OSS emulation
and ossp to occupy the same kernel.
I don't see how I would be able to achieve the latter with one liner.
Can you please elaborate a little bit?
Thanks.
--
tejun
next prev parent reply other threads:[~2009-08-05 16:00 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
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 [this message]
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=4A79AD2A.4060308@suse.de \
--to=teheo@suse.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cguthrie@mandriva.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@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