Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Jul 2009 15:52:08 +0200
From:      Hans Petter Selasky <hselasky@c2i.net>
To:        freebsd-current@freebsd.org
Cc:        usb@freebsd.org, Andriy Gapon <avg@icyb.net.ua>, Andrew Thompson <thompsa@freebsd.org>, Maksim Yevmenkin <maksim.yevmenkin@gmail.com>
Subject:   Re: USB polling (75% done)
Message-ID:  <200907241552.10763.hselasky@c2i.net>
In-Reply-To: <4A69AB91.2010208@icyb.net.ua>
References:  <1280352d0907101020q69f494cdndb01ff14ecf7ea8c@mail.gmail.com> <bb4a86c70907231123l494f3a38vaf33076525ca11f@mail.gmail.com> <4A69AB91.2010208@icyb.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 24 July 2009 14:39:45 Andriy Gapon wrote:
> Maybe Giant asserts in ukbd are not needed?

Option 1) They are needed as long as ukbd is not allowed to lock Giant when it 
needs it. Like when you are at the console and have Scroll-Lock pressed, and 
then something is printed, then printf() will directly call into the keyboard 
layer, to disable scroll lock and its associated LED. Locking Giant from a 
sub-routine of printf() is not smart and leads to LOR's. Having an AT-keyboard 
you can always peek or poke a port directly, but an USB-keyboard is quite more 
advanced. And like some other guy pointed out recently: In some cases the 
keyboard gets enabled without Giant locked, even though that is a requirement.

Option 2) Some work is needed to get the non-USB part of the statemachine in 
ukbd out of Giant. I'm not a kbdmux expert either. I don't have the full 
overview from where the variables in the ukbd's keyboard state can be read and 
written, and which fields in the ukbd's keyboard state needs to remain Giant 
locked due to kbdmux and kbd. That's basically what is stopping me from 
converting ukbd free of Giant.

Option 3) Assume that the kernel never panics :-)

--HPS




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907241552.10763.hselasky>