kern_yield vs ukbd_yield

[Hans Petter Selasky]

On Saturday 17 December 2011 15:57:30 Andriy Gapon wrote:
> Replying further...
> 
> > Not directly, but indirect. You know, if you pause thread 1 (which I
> > thought was thread 0), then other thread will get a chance to run.
> 
> pause() could be a sufficient action to let other thread run, but it is not
> a required action.  As we've already discusses earlier all the USB threads
> have sufficiently high priorities to get runnable while other kernel
> threads are runnable.  Only certain interrupt threads could have prevented
> them from running, but that's definitely not the case.
> 
> > It might also be that Giant is locked by syscons, and that unless you
> > pause or yield, then Giant will block other parts of USB, like the
> > callback thread, which is Giant locked for ukbd only to run.
> > 

Hi,

> > Maybe that is the explanation?
> 
> Not sure if you are hypothesizing or if this is something that you
> experienced during development and testing.

I have only observed that no key-presses are returned by the UKBD polling 
mechanism, if the ukbd_yield() is removed. I have not investigated this 
further.

If you use pause() that will slowdown dumphandling which is also polling for 
key-presses, so this must be added conditionally.

> 
> Let's consider a few observations.
> 
> First, syscons doesn't acquire Giant anywhere in the path started from
> cngetc. Actually, I believe that the only place where Giant is now
> explicitly acquired in the whole syscons code can be safely replaced with
> an assert that the Giant is already held.
> 
> Second, the polling mode is designed to be usable in situations where other
> threads are not running.  So in general it should not depend on other
> threads being able to make any progress.

Sure, but it is not that simple to poll a key-press from USB like with AT 
keyboards. You need to go through a bunch of stuff, including busdma before 
you get the keypress.

--HPS