Re: USB polling (75% done)

On Fri, Jul 24, 2009 at 5:39 AM, Andriy Gapon<avg_at_icyb.net.ua> wrote:
> on 23/07/2009 21:23 Maksim Yevmenkin said the following:
>> On Tue, Jul 21, 2009 at 5:20 AM, Hans Petter Selasky<hselasky_at_c2i.net> wrote:
>>> On Monday 20 July 2009 23:51:41 Alfred Perlstein wrote:
>>>> * Hans Petter Selasky <hselasky_at_c2i.net> [090715 13:37] wrote:
> ...
>>>>> Using USB keyboard in KDB: Does not work because Giant is not locked when
>>>>> calling into the UKBD's get char routine. UKBD is Giant locked. Someone
>>>>> familiar with the keyboard system on FreeBSD please step forward and fix
>>>>> this so that UKBD gets independent of the Giant mutex.
>>>> the ukbd driver needs giant?
>>> I think the keyboard mux is under Giant, and does not have any concept about
>>> mutexes. Most simple solution would be that DDB locks Giant before entering
>>> into the keyboard code.
>>
>> as i understand it, keyboard drivers (and kbdmux(4) is a keyboard
>> driver), can/should not use any locks. period. so whatever calls into
>> keyboard driver should take care of locking.
>
> Maybe I am missing something but I do not see any explicit locking or lock
> assertions in kbdmux code. All lock defines are under #if 0.

that is what i said, no? :) keyboard drivers can/should not use any locks.

> kbdmux does use taskqueue_swi_giant though. Tasks are queued on it in
> kbdmux_kbd_intr_timo (periodic callout) and in kbdmux_kbd_event (kbd callback).

so? it only means that callout will be called with giant held. which
is exactly what i said, whatever calls into keyboard driver should
take care of locking.

> But, these shouldn't get called in polling mode, right? (because there shouldn't
> be any interrupts)

well, there is polling mode and then there is polling mode :) when ddb
is active, yes, there should not be any interrupts, however, there are
cases when keyboard is running in polled mode with interrupts enabled.
for example, mountroot prompt, geli passphrase prompt, etc.

> Maybe Giant asserts in ukbd are not needed?
> Or should be asserted only in "normal" mode?

again, as far as i understand it, keyboard driver should/can not use
any locks. imo, it means that keyboard driver generally should/can not
assert on any lock as well. if system drops into ddb because it has
panic'ed, any lock can be in any state (potentially) .

thanks,
max