This email brought to you by Sunday afternoon coding frustration.
As I move forward with Ubuntu's next release, I keep running into very
familiar problems, more and more often. The issues stem from userspace
not having enough control over what the kernel decides to do with a
device, and possible drivers to bind it with.
Here's a common case I'm trying to address:
Driver foo supports devices a, b
Driver bar supports devices b, c
For devices 'a' and 'c', the answer is simple. The correct driver always
gets loaded. However, the answer is not always simple for device 'b'. At
first glance, you could assume that either driver would be correct, but
that's wrong.
There's two main reasons why foo and bar may not be interchangeable for
device 'b'.
First, foo may not work correctly with all variations of device 'b', and
the same for driver bar. Since driver loading and binding only works
based on the identity 'b', there's no more information to base the
decision on, other than the user deciding it for us.
Secondly, foo and bar may be different ways of handling the same device.
An example that comes to mind is a bt878 chipset where the audio portion
can be handled by a media driver or a sound driver. The user has to
decide which driver they want handling that device based on how they use
it.
So this then becomes a decision that the kernel cannot make. As a
distro, we have to provide both drivers, but the endless support for
people who have broken systems because driver foo doesn't work with
their device, or because driver foo doesn't use their device in the way
they want, are having to be told to blacklist foo so bar will be used.
I don't think blacklisting is very ideal. For example let's say they
have device 'a' and 'b'. Since 'a' needs foo, we then need to tell them
how to make sure bar gets loaded first (usually by force loading rather
than the tidy udev handling) so that their 'b' device binds with it
first.
If this is a hot-pluggable device, they're just fucked. If both drivers
are already loaded into the kernel, userspace has no control over which
one the kernel decides to bind with, and the kernel doesn't have all the
info needed.
Either way, we've butchered their system to work around a lack of
functionality. Upgrades are likely going to be broken, or become
difficult, etc.
So my ultimate goal is to somehow move this decision making to udev. My
plan is something along these lines:
- udev is started, and if it supports this new model, somehow tells the
driver core to disable its internal binding of drivers.
- udev gets notification of new device
- udev loads all drivers capable of handling device (if it doesn't
support this new model, then it works like it used to, and the next step
is skipped).
- udev checks it's rules, if a specific driver is requested for a
device, emit a sysfs write to bind with it. If no driver specific
request is made, then emit an "any" bind, to let the kernel do whatever
it wants.
Internally in the kernel, binding would still be enforced by driver core
matching/probing. The above setup would also intermix well with udev
rules that forced binding (e.g. new_id for PCI drivers/devices).
What I haven't done is figure out what this interface between udev and
driver core will look like.
Comments welcome. And if there's already a clean way to do this that I
just don't know about, please kick me toward it.
On Sun, 2006-11-12 at 15:39 -0800, Ben Collins wrote:
> This email brought to you by Sunday afternoon coding frustration.
>
> As I move forward with Ubuntu's next release, I keep running into very
> familiar problems, more and more often. The issues stem from userspace
> not having enough control over what the kernel decides to do with a
> device, and possible drivers to bind it with.
>
> Here's a common case I'm trying to address:
>
> Driver foo supports devices a, b
> Driver bar supports devices b, c
>
> For devices 'a' and 'c', the answer is simple. The correct driver always
> gets loaded. However, the answer is not always simple for device 'b'. At
> first glance, you could assume that either driver would be correct, but
> that's wrong.
>
> There's two main reasons why foo and bar may not be interchangeable for
> device 'b'.
>
> First, foo may not work correctly with all variations of device 'b', and
> the same for driver bar. Since driver loading and binding only works
> based on the identity 'b', there's no more information to base the
> decision on, other than the user deciding it for us.
>
> Secondly, foo and bar may be different ways of handling the same device.
> An example that comes to mind is a bt878 chipset where the audio portion
> can be handled by a media driver or a sound driver. The user has to
> decide which driver they want handling that device based on how they use
> it.
>
> So this then becomes a decision that the kernel cannot make. As a
> distro, we have to provide both drivers, but the endless support for
> people who have broken systems because driver foo doesn't work with
> their device, or because driver foo doesn't use their device in the way
> they want, are having to be told to blacklist foo so bar will be used.
>
> I don't think blacklisting is very ideal. For example let's say they
> have device 'a' and 'b'. Since 'a' needs foo, we then need to tell them
> how to make sure bar gets loaded first (usually by force loading rather
> than the tidy udev handling) so that their 'b' device binds with it
> first.
>
> If this is a hot-pluggable device, they're just fucked. If both drivers
> are already loaded into the kernel, userspace has no control over which
> one the kernel decides to bind with, and the kernel doesn't have all the
> info needed.
>
> Either way, we've butchered their system to work around a lack of
> functionality. Upgrades are likely going to be broken, or become
> difficult, etc.
>
> So my ultimate goal is to somehow move this decision making to udev. My
> plan is something along these lines:
>
> - udev is started, and if it supports this new model, somehow tells the
> driver core to disable its internal binding of drivers.
>
> - udev gets notification of new device
>
> - udev loads all drivers capable of handling device (if it doesn't
> support this new model, then it works like it used to, and the next step
> is skipped).
>
> - udev checks it's rules, if a specific driver is requested for a
> device, emit a sysfs write to bind with it. If no driver specific
> request is made, then emit an "any" bind, to let the kernel do whatever
> it wants.
>
> Internally in the kernel, binding would still be enforced by driver core
> matching/probing. The above setup would also intermix well with udev
> rules that forced binding (e.g. new_id for PCI drivers/devices).
>
> What I haven't done is figure out what this interface between udev and
> driver core will look like.
>
> Comments welcome. And if there's already a clean way to do this that I
> just don't know about, please kick me toward it.
>
What's wrong with making udev or whatever unbind driver A and then bind
driver B if the driver bound by the kernel ends up being the wrong
choice? (Besides the inelegance of the kernel choosing one and then
userspace immediately choosing the other, of course.)
I'd argue that having multiple drivers for the same hardware is a bit
strange to begin with, but that's another issue entirely.
--
Nicholas Miell <[email protected]>
On Sun, 2006-11-12 at 16:49 -0800, Nicholas Miell wrote:
> On Sun, 2006-11-12 at 15:39 -0800, Ben Collins wrote:
>
> What's wrong with making udev or whatever unbind driver A and then bind
> driver B if the driver bound by the kernel ends up being the wrong
> choice? (Besides the inelegance of the kernel choosing one and then
> userspace immediately choosing the other, of course.)
>
> I'd argue that having multiple drivers for the same hardware is a bit
> strange to begin with, but that's another issue entirely.
If two drivers are loaded for the same device, there's no way for udev
to tell the kernel which driver to use for a device, that I know of.
Also, that just sounds very horrible to do. If you have udev/dbus events
flying around for "device present", "device gone", "device present",
then it could make for a very ugly user experience (think of programs to
handle devices being started because of these events).
On Sun, 2006-11-12 at 17:24 -0800, Ben Collins wrote:
> On Sun, 2006-11-12 at 16:49 -0800, Nicholas Miell wrote:
> > On Sun, 2006-11-12 at 15:39 -0800, Ben Collins wrote:
> >
> > What's wrong with making udev or whatever unbind driver A and then bind
> > driver B if the driver bound by the kernel ends up being the wrong
> > choice? (Besides the inelegance of the kernel choosing one and then
> > userspace immediately choosing the other, of course.)
> >
> > I'd argue that having multiple drivers for the same hardware is a bit
> > strange to begin with, but that's another issue entirely.
>
> If two drivers are loaded for the same device, there's no way for udev
> to tell the kernel which driver to use for a device, that I know of.
/sys/bus/*/drivers/*/{bind,unbind}
> Also, that just sounds very horrible to do. If you have udev/dbus events
> flying around for "device present", "device gone", "device present",
> then it could make for a very ugly user experience (think of programs to
> handle devices being started because of these events).
So don't fire the events until after the final binding.
--
Nicholas Miell <[email protected]>
On Sun, 2006-11-12 at 17:47 -0800, Nicholas Miell wrote:
> On Sun, 2006-11-12 at 17:24 -0800, Ben Collins wrote:
> > On Sun, 2006-11-12 at 16:49 -0800, Nicholas Miell wrote:
> > > On Sun, 2006-11-12 at 15:39 -0800, Ben Collins wrote:
> > >
> > > What's wrong with making udev or whatever unbind driver A and then bind
> > > driver B if the driver bound by the kernel ends up being the wrong
> > > choice? (Besides the inelegance of the kernel choosing one and then
> > > userspace immediately choosing the other, of course.)
> > >
> > > I'd argue that having multiple drivers for the same hardware is a bit
> > > strange to begin with, but that's another issue entirely.
> >
> > If two drivers are loaded for the same device, there's no way for udev
> > to tell the kernel which driver to use for a device, that I know of.
>
> /sys/bus/*/drivers/*/{bind,unbind}
"bind" does not tell the driver core to "bind this device with this
driver", it tells it to "bind this driver to whatever devices we match
that aren't already bound".
That doesn't solve my use case.
> > Also, that just sounds very horrible to do. If you have udev/dbus events
> > flying around for "device present", "device gone", "device present",
> > then it could make for a very ugly user experience (think of programs to
> > handle devices being started because of these events).
>
> So don't fire the events until after the final binding.
It's still not a correct solution. If we want a specific driver to be
bound to a specific device, userspace shouldn't have to jump through
hoops to do it. It should be simple and clean.
The suggestions you are giving require userspace to work around a
deficiency in the kernel, by guessing the ordering requirements to
satisfy what the user wants. In cases of hotplugging, it is also
sometimes impossible to satisfy these requirements using the current
scheme.
On Sun, 2006-11-12 at 21:22 -0800, Ben Collins wrote:
> On Sun, 2006-11-12 at 17:47 -0800, Nicholas Miell wrote:
> > On Sun, 2006-11-12 at 17:24 -0800, Ben Collins wrote:
> > > On Sun, 2006-11-12 at 16:49 -0800, Nicholas Miell wrote:
> > > > On Sun, 2006-11-12 at 15:39 -0800, Ben Collins wrote:
> > > >
> > > > What's wrong with making udev or whatever unbind driver A and then bind
> > > > driver B if the driver bound by the kernel ends up being the wrong
> > > > choice? (Besides the inelegance of the kernel choosing one and then
> > > > userspace immediately choosing the other, of course.)
> > > >
> > > > I'd argue that having multiple drivers for the same hardware is a bit
> > > > strange to begin with, but that's another issue entirely.
> > >
> > > If two drivers are loaded for the same device, there's no way for udev
> > > to tell the kernel which driver to use for a device, that I know of.
> >
> > /sys/bus/*/drivers/*/{bind,unbind}
>
> "bind" does not tell the driver core to "bind this device with this
> driver", it tells it to "bind this driver to whatever devices we match
> that aren't already bound".
>
> That doesn't solve my use case.
I don't have any hardware with multiple drivers lying around, but I'm
fairly certain you can write the bus ID of a device into driver A's
unbind file and then follow that with a write of that bus ID into driver
B's bind file and get the effect that you want.
>
> > > Also, that just sounds very horrible to do. If you have udev/dbus events
> > > flying around for "device present", "device gone", "device present",
> > > then it could make for a very ugly user experience (think of programs to
> > > handle devices being started because of these events).
> >
> > So don't fire the events until after the final binding.
>
> It's still not a correct solution. If we want a specific driver to be
> bound to a specific device, userspace shouldn't have to jump through
> hoops to do it. It should be simple and clean.
>
> The suggestions you are giving require userspace to work around a
> deficiency in the kernel, by guessing the ordering requirements to
> satisfy what the user wants. In cases of hotplugging, it is also
> sometimes impossible to satisfy these requirements using the current
> scheme.
Well, the kernel's deficiency is that there's multiple drivers for the
same hardware, not that userspace doesn't get first say in how hardware
is bound to drivers.
--
Nicholas Miell <[email protected]>
On Sun, 2006-11-12 at 22:45 -0800, Nicholas Miell wrote:
> On Sun, 2006-11-12 at 21:22 -0800, Ben Collins wrote:
> > On Sun, 2006-11-12 at 17:47 -0800, Nicholas Miell wrote:
> > > On Sun, 2006-11-12 at 17:24 -0800, Ben Collins wrote:
> > > > On Sun, 2006-11-12 at 16:49 -0800, Nicholas Miell wrote:
> > > > > On Sun, 2006-11-12 at 15:39 -0800, Ben Collins wrote:
> > > > >
> > > > > What's wrong with making udev or whatever unbind driver A and then bind
> > > > > driver B if the driver bound by the kernel ends up being the wrong
> > > > > choice? (Besides the inelegance of the kernel choosing one and then
> > > > > userspace immediately choosing the other, of course.)
> > > > >
> > > > > I'd argue that having multiple drivers for the same hardware is a bit
> > > > > strange to begin with, but that's another issue entirely.
> > > >
> > > > If two drivers are loaded for the same device, there's no way for udev
> > > > to tell the kernel which driver to use for a device, that I know of.
> > >
> > > /sys/bus/*/drivers/*/{bind,unbind}
> >
> > "bind" does not tell the driver core to "bind this device with this
> > driver", it tells it to "bind this driver to whatever devices we match
> > that aren't already bound".
> >
> > That doesn't solve my use case.
>
> I don't have any hardware with multiple drivers lying around, but I'm
> fairly certain you can write the bus ID of a device into driver A's
> unbind file and then follow that with a write of that bus ID into driver
> B's bind file and get the effect that you want.
Certainly, that's the case. However, it should be possible to do this
without letting the kernel bind a device to one driver, just to go back
and unbind it, and bind to another driver.
> >
> > > > Also, that just sounds very horrible to do. If you have udev/dbus events
> > > > flying around for "device present", "device gone", "device present",
> > > > then it could make for a very ugly user experience (think of programs to
> > > > handle devices being started because of these events).
> > >
> > > So don't fire the events until after the final binding.
> >
> > It's still not a correct solution. If we want a specific driver to be
> > bound to a specific device, userspace shouldn't have to jump through
> > hoops to do it. It should be simple and clean.
> >
> > The suggestions you are giving require userspace to work around a
> > deficiency in the kernel, by guessing the ordering requirements to
> > satisfy what the user wants. In cases of hotplugging, it is also
> > sometimes impossible to satisfy these requirements using the current
> > scheme.
>
> Well, the kernel's deficiency is that there's multiple drivers for the
> same hardware, not that userspace doesn't get first say in how hardware
> is bound to drivers.
No, in a lot of cases, it's not a deficiency. Take the entire
drivers/ata/pata_*.ko list. All of them match an IDE driver, however the
pata driver most times does not support all the same PCI id's for the
matching ide driver.
Also the other case I gave where there is an alsa driver and a media
driver for the same chipset, is by design. It can't be helped. There
actually is a case for wanting one driver or the other in the case of
the exact same hardware, depending on the users desire.
>
> So my ultimate goal is to somehow move this decision making to udev. My
> plan is something along these lines:
well today you can already unbind from userspace.
The decision to bind automatically is the right one for the kernel,
since that is by far the most common one (99.9%+ of stuff has only one
driver ever) and also if you have no drivers it's just hard for udev to
run at all :)
udev can already unbind those few really rare cases it cares about, and
then do the other driver and bind that......
Now; there is a second issue. If the choice for one or the other is
consistent, we should consider fixing the kernel drivers to just not
advertise the b0rked one.. (this assumes that both drivers are in the
kernel and both are open source)
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
Hello!
> No, in a lot of cases, it's not a deficiency. Take the entire
> drivers/ata/pata_*.ko list. All of them match an IDE driver, however the
> pata driver most times does not support all the same PCI id's for the
> matching ide driver.
>
> Also the other case I gave where there is an alsa driver and a media
> driver for the same chipset, is by design. It can't be helped. There
> actually is a case for wanting one driver or the other in the case of
> the exact same hardware, depending on the users desire.
If you have two drivers for the same device, there is no problem --
just insmod one of the drivers. The ugly cases are the "a b / b c"
described in the first mail of this thread -- however, are these really
sane? Shouldn't they be split to multiple drivers?
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
A bug in the code is worth two in the documentation.
On Sun, 2006-11-12 at 23:10 -0800, Ben Collins wrote:
> Also the other case I gave where there is an alsa driver and a media
> driver for the same chipset, is by design. It can't be helped. There
> actually is a case for wanting one driver or the other in the case of
> the exact same hardware, depending on the users desire.
That one looks ugly. Probably the same driver should have a media
interface as well as an alsa interface (like alsa device are also oss
devices, no need to play evil rmmod/insmod tricks anymore).
Xav
On Mon, 2006-11-13 at 08:58 +0100, Arjan van de Ven wrote:
> Now; there is a second issue. If the choice for one or the other is
> consistent, we should consider fixing the kernel drivers to just not
> advertise the b0rked one.. (this assumes that both drivers are in the
> kernel and both are open source)
Unfortunately it becomes political quickly. For example the old OSS
i810_audio driver is still in the kernel even though the ALSA driver
supports more hardware and provides more functionality because some
people consider the ALSA driver bloated.
Lee
On Mon, 2006-11-13 at 13:51 -0500, Lee Revell wrote:
> On Mon, 2006-11-13 at 08:58 +0100, Arjan van de Ven wrote:
> > Now; there is a second issue. If the choice for one or the other is
> > consistent, we should consider fixing the kernel drivers to just not
> > advertise the b0rked one.. (this assumes that both drivers are in the
> > kernel and both are open source)
>
> Unfortunately it becomes political quickly. For example the old OSS
> i810_audio driver is still in the kernel even though the ALSA driver
> supports more hardware and provides more functionality because some
> people consider the ALSA driver bloated.
I doubt distros ship both though.... I thought all distros were
alsa-only by now..
also this is a case of "full overlap", which isn't a real problem (it's
just policy which module to load); the problem is when you NEED 2
modules to get full coverage and then they overlap..
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
On 11/13/06 09:18:59PM +0100, Arjan van de Ven wrote:
> On Mon, 2006-11-13 at 13:51 -0500, Lee Revell wrote:
> > On Mon, 2006-11-13 at 08:58 +0100, Arjan van de Ven wrote:
> > > Now; there is a second issue. If the choice for one or the other is
> > > consistent, we should consider fixing the kernel drivers to just not
> > > advertise the b0rked one.. (this assumes that both drivers are in the
> > > kernel and both are open source)
> >
> > Unfortunately it becomes political quickly. For example the old OSS
> > i810_audio driver is still in the kernel even though the ALSA driver
> > supports more hardware and provides more functionality because some
> > people consider the ALSA driver bloated.
>
> I doubt distros ship both though.... I thought all distros were
> alsa-only by now..
>
I know that Debian ships both because I have to switch back to the OSS
driver whenever I want to play one of those closed source games that mmap
/dev/dsp because the ALSA OSS emulation can't seem to handle having the
device opened via ALSA and /dev/dsp at the same time and the aoss wrapper
doesn't work for apps that use mmap on /dev/dsp.
Jim.
On Mon, 2006-11-13 at 17:16 -0500, Jim Crilly wrote:
> I know that Debian ships both because I have to switch back to the OSS
> driver whenever I want to play one of those closed source games that
> mmap /dev/dsp because the ALSA OSS emulation can't seem to handle
> having the device opened via ALSA and /dev/dsp at the same time and
> the aoss wrapper doesn't work for apps that use mmap on /dev/dsp.
>
This should work with the ALSA /dev/dsp emulation, if you kill all other
sound using apps before launching the game (which the OSS driver also
requires).
Lee
On 11/13/06 05:59:08PM -0500, Lee Revell wrote:
> On Mon, 2006-11-13 at 17:16 -0500, Jim Crilly wrote:
> > I know that Debian ships both because I have to switch back to the OSS
> > driver whenever I want to play one of those closed source games that
> > mmap /dev/dsp because the ALSA OSS emulation can't seem to handle
> > having the device opened via ALSA and /dev/dsp at the same time and
> > the aoss wrapper doesn't work for apps that use mmap on /dev/dsp.
> >
>
> This should work with the ALSA /dev/dsp emulation, if you kill all other
> sound using apps before launching the game (which the OSS driver also
> requires).
>
Well it doesn't and the only error I get from the game is:
/dev/dsp: Input/output error
Could not mmap /dev/dsp
If it makes a difference, lspci lists the card as:
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio
Controller (rev a2)
Jim.
On Mon, 2006-11-13 at 18:22 -0500, Jim Crilly wrote:
> Well it doesn't and the only error I get from the game is:
>
> /dev/dsp: Input/output error
> Could not mmap /dev/dsp
>
> If it makes a difference, lspci lists the card as:
>
> 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97
> Audio Controller (rev a2)
Please see http://www.alsa-project.org/~iwai/OSS-Emulation.html.
You need something like:
$ echo "quake 0 0 direct" > /proc/asound/card0/pcm0p/oss
Lee
On 11/13/06 06:45:01PM -0500, Lee Revell wrote:
> On Mon, 2006-11-13 at 18:22 -0500, Jim Crilly wrote:
> > Well it doesn't and the only error I get from the game is:
> >
> > /dev/dsp: Input/output error
> > Could not mmap /dev/dsp
> >
> > If it makes a difference, lspci lists the card as:
> >
> > 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97
> > Audio Controller (rev a2)
>
> Please see http://www.alsa-project.org/~iwai/OSS-Emulation.html.
>
> You need something like:
>
> $ echo "quake 0 0 direct" > /proc/asound/card0/pcm0p/oss
>
Yea, I've read that FAQ and I vaguely remember trying that although that
might have been for something different because it appears to be working
now. I can't actually verify the sound is working though since I'm not
physically at the box.
Sorry for the noise.
Jim.
On Mon, 2006-11-13 at 17:16 -0500, Jim Crilly wrote:
> On 11/13/06 09:18:59PM +0100, Arjan van de Ven wrote:
> > On Mon, 2006-11-13 at 13:51 -0500, Lee Revell wrote:
> > > On Mon, 2006-11-13 at 08:58 +0100, Arjan van de Ven wrote:
> > > > Now; there is a second issue. If the choice for one or the other is
> > > > consistent, we should consider fixing the kernel drivers to just not
> > > > advertise the b0rked one.. (this assumes that both drivers are in the
> > > > kernel and both are open source)
> > >
> > > Unfortunately it becomes political quickly. For example the old OSS
> > > i810_audio driver is still in the kernel even though the ALSA driver
> > > supports more hardware and provides more functionality because some
> > > people consider the ALSA driver bloated.
> >
> > I doubt distros ship both though.... I thought all distros were
> > alsa-only by now..
> >
>
> I know that Debian ships both because I have to switch back to the OSS
> driver whenever I want to play one of those closed source games that mmap
> /dev/dsp because the ALSA OSS emulation can't seem to handle having the
> device opened via ALSA and /dev/dsp at the same time and the aoss wrapper
> doesn't work for apps that use mmap on /dev/dsp.
and this is why shipping 2 drivers suck.
"A has a bug so I need to use B" is the wrong answer, at least long
term. The real answer is "fix A".
I know it sucks for you, but if shipping B means A doesn't get fixed, or
worse, bugs in A hardly get reported... it means the short term is
hurting the long term, and just prolongs the pain even for you...
(since switching drivers is a pain, and more and more stuff is depending
on alsa nowadays)
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
On 11/14/06 08:32:00AM +0100, Arjan van de Ven wrote:
> On Mon, 2006-11-13 at 17:16 -0500, Jim Crilly wrote:
> > I know that Debian ships both because I have to switch back to the OSS
> > driver whenever I want to play one of those closed source games that mmap
> > /dev/dsp because the ALSA OSS emulation can't seem to handle having the
> > device opened via ALSA and /dev/dsp at the same time and the aoss wrapper
> > doesn't work for apps that use mmap on /dev/dsp.
>
> and this is why shipping 2 drivers suck.
> "A has a bug so I need to use B" is the wrong answer, at least long
> term. The real answer is "fix A".
> I know it sucks for you, but if shipping B means A doesn't get fixed, or
> worse, bugs in A hardly get reported... it means the short term is
> hurting the long term, and just prolongs the pain even for you...
> (since switching drivers is a pain, and more and more stuff is depending
> on alsa nowadays)
>
For the most part I agree and if the OSS emulation in ALSA was better I
would agree completely. But the fact that nothing can use /dev/dsp because
the device doesn't do hardware mixing and some apps are already using the
device via ALSA really sucks. Switching drivers is the least painful part
of the process, the real pain comes from having to kill all of the ALSA
apps to be able to use /dev/dsp in either case. I know that this has
been discussed before and no one has come up with a good way to make the
OSS emulation work with ALSA so I won't push the issue. And Doom3's last
patch did include ALSA support so maybe that's a sign that OSS is really
a thing of the past even in closed source apps.
Jim.
On Sun, Nov 12, 2006 at 09:22:44PM -0800, Ben Collins wrote:
> On Sun, 2006-11-12 at 17:47 -0800, Nicholas Miell wrote:
> > On Sun, 2006-11-12 at 17:24 -0800, Ben Collins wrote:
> > > On Sun, 2006-11-12 at 16:49 -0800, Nicholas Miell wrote:
> > > > On Sun, 2006-11-12 at 15:39 -0800, Ben Collins wrote:
> > > >
> > > > What's wrong with making udev or whatever unbind driver A and then bind
> > > > driver B if the driver bound by the kernel ends up being the wrong
> > > > choice? (Besides the inelegance of the kernel choosing one and then
> > > > userspace immediately choosing the other, of course.)
> > > >
> > > > I'd argue that having multiple drivers for the same hardware is a bit
> > > > strange to begin with, but that's another issue entirely.
> > >
> > > If two drivers are loaded for the same device, there's no way for udev
> > > to tell the kernel which driver to use for a device, that I know of.
> >
> > /sys/bus/*/drivers/*/{bind,unbind}
>
> "bind" does not tell the driver core to "bind this device with this
> driver", it tells it to "bind this driver to whatever devices we match
> that aren't already bound".
No it does not, it tells the driver core to "bind this device with this
driver, _if_ the driver will accept it".
> That doesn't solve my use case.
Yes it does:
echo -n BUS_ID > /sys/bus/foo_bus/drivers/foo_driver/unbind
echo -n BUS_ID > /sys/bus/foo_bus/drivers/baz_driver/bind
and you are set. That's the way other distros use this functionality :)
thanks,
greg k-h
On 11/23/06, Greg KH <[email protected]> wrote:
> On Sun, Nov 12, 2006 at 09:22:44PM -0800, Ben Collins wrote:
> > On Sun, 2006-11-12 at 17:47 -0800, Nicholas Miell wrote:
> > > On Sun, 2006-11-12 at 17:24 -0800, Ben Collins wrote:
> > > > On Sun, 2006-11-12 at 16:49 -0800, Nicholas Miell wrote:
> > > > > On Sun, 2006-11-12 at 15:39 -0800, Ben Collins wrote:
> > > > >
> > > > > What's wrong with making udev or whatever unbind driver A and then bind
> > > > > driver B if the driver bound by the kernel ends up being the wrong
> > > > > choice? (Besides the inelegance of the kernel choosing one and then
> > > > > userspace immediately choosing the other, of course.)
> > > > >
> > > > > I'd argue that having multiple drivers for the same hardware is a bit
> > > > > strange to begin with, but that's another issue entirely.
> > > >
> > > > If two drivers are loaded for the same device, there's no way for udev
> > > > to tell the kernel which driver to use for a device, that I know of.
> > >
> > > /sys/bus/*/drivers/*/{bind,unbind}
> >
> > "bind" does not tell the driver core to "bind this device with this
> > driver", it tells it to "bind this driver to whatever devices we match
> > that aren't already bound".
>
> No it does not, it tells the driver core to "bind this device with this
> driver, _if_ the driver will accept it".
>
> > That doesn't solve my use case.
>
> Yes it does:
> echo -n BUS_ID > /sys/bus/foo_bus/drivers/foo_driver/unbind
> echo -n BUS_ID > /sys/bus/foo_bus/drivers/baz_driver/bind
>
> and you are set. That's the way other distros use this functionality :)
Right, I currently port that part of SUSE's sysconfig's per-device
configuration to udev, and udev-rules will be able to specify what
driver to use for a device, including driver-unbinding/binding.
Also modprobe will be built into udev to solve the
performance-problems we see with parsing the modprobe-files for every
device with a modalias.
Kay
On Thu, Nov 23, 2006 at 12:40:04PM +0100, Kay Sievers wrote:
> On 11/23/06, Greg KH <[email protected]> wrote:
> >On Sun, Nov 12, 2006 at 09:22:44PM -0800, Ben Collins wrote:
> >> On Sun, 2006-11-12 at 17:47 -0800, Nicholas Miell wrote:
> >> > On Sun, 2006-11-12 at 17:24 -0800, Ben Collins wrote:
> >> > > On Sun, 2006-11-12 at 16:49 -0800, Nicholas Miell wrote:
> >> > > > On Sun, 2006-11-12 at 15:39 -0800, Ben Collins wrote:
> >> > > >
> >> > > > What's wrong with making udev or whatever unbind driver A and then
> >bind
> >> > > > driver B if the driver bound by the kernel ends up being the wrong
> >> > > > choice? (Besides the inelegance of the kernel choosing one and then
> >> > > > userspace immediately choosing the other, of course.)
> >> > > >
> >> > > > I'd argue that having multiple drivers for the same hardware is a
> >bit
> >> > > > strange to begin with, but that's another issue entirely.
> >> > >
> >> > > If two drivers are loaded for the same device, there's no way for
> >udev
> >> > > to tell the kernel which driver to use for a device, that I know of.
> >> >
> >> > /sys/bus/*/drivers/*/{bind,unbind}
> >>
> >> "bind" does not tell the driver core to "bind this device with this
> >> driver", it tells it to "bind this driver to whatever devices we match
> >> that aren't already bound".
> >
> >No it does not, it tells the driver core to "bind this device with this
> >driver, _if_ the driver will accept it".
> >
> >> That doesn't solve my use case.
> >
> >Yes it does:
> > echo -n BUS_ID > /sys/bus/foo_bus/drivers/foo_driver/unbind
> > echo -n BUS_ID > /sys/bus/foo_bus/drivers/baz_driver/bind
> >
> >and you are set. That's the way other distros use this functionality :)
>
> Right, I currently port that part of SUSE's sysconfig's per-device
> configuration to udev, and udev-rules will be able to specify what
> driver to use for a device, including driver-unbinding/binding.
>
> Also modprobe will be built into udev to solve the
> performance-problems we see with parsing the modprobe-files for every
> device with a modalias.
Nice, that will make things even faster at boot time.
thanks,
greg k-h