Re: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patchadded to gregkh-2.6 tree

[Stas Sergeev]

Hello.

Takashi Iwai wrote:
>> I was trying this in the past.
>> This never worked out very well.
> Why?
Mainly because I was not able to
come up with the good hooks for the
pcspkr driver, and those I tried,
were not applied.
There was a lengthy thread about that.
Now I can't find its beginning and its
end, but some is here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/3096.html
I also think you were CCed, but maybe
not.

>> I disliked the dependancies.
>> Either snd-pcsp was loading pcspkr,
>> or there had to be the global variable
>> to prevent the concurrent access, and
>> that hurts modularity.
> But you anyway enable the input pcspkr feature in your snd-pcsp code.
> So, basically you depend on (or build on) it.
If they are separate, then "rmmod pcspkr"
should disable the beeps. I don't want
to fuzzy that logic up to something like
- Check if snd-pcsp is loaded
- Use alsamixer to disable beeps, if
it is.
- Use rmmod pcspkr if it is not.
I think there should be always a single
way for the user to disable the beeps.
Now he can choose it by chosing the driver.

>>> What we'd need is a hook on
>>> pcspkr.c that adds a dynamic check whether snd-pcsp (or any ohter)
>>> is running.
>> How?
> What you need is a way to check whether input pcspkr can be usable or
> not.  You can add a function pointer, for example.
Could you please clarify?
- Should snd-pcsp then forcibly select
pcspkr.c to compile?
- What exactly function pointer, and
where to add?

>> And also, with snd-pcsp you have a
>> mixer control to disable the beeps,
>> which I find sometimes even more
>> usefull than the pcm sound itself. :)
> Yes, that seems useful.
Yes, but problematic when they are separate.
I was trying to add an input event to shut
up pcspkr.c, but that was rejected. Everything
else will introduce the dependancy. The
dependancy will block rmmod, obfuscating the
logic of disabling the beeps.
Just for the record, what problems do you
see with the current solution, where only
one driver drives the device? That looks
rather logical to me. And I also can remember
the complains about pcspkr driver being in
an input drivers section. Some people had
problems finding it there and were asking
to move it to sound menu.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/