Re: timing code in 2.6.1

[Andrew Morton <akpm@osdl.org>]

"Richard B. Johnson" <root@chaos.analogic.com> wrote:
>
> 
> Some drivers are being re-written for 2.6++. The following
> construct seems to work for "waiting for an event" in
> the kernel modules.
> 
>         // No locks are being held
>         tim = jiffies + EVENT_TIMEOUT;
>         while(!event() && time_before(jiffies, tim))
>             schedule_timeout(0);
> 
> Is there anything wrong?

This is not a good thing to be doing.  You should add this task to a
waitqueue and then sleep.  Make the code which causes event() to come true
deliver a wake_up to that waitqueue.  There are many examples of this in
the kernel.

If the hardware only supports polling then gee, you'd be best off spinning
for a few microseconds then fall into a schedule_timeout(1) polling loop. 
Or something like that.  Or make the hardware designer write the damn
driver.

> Do I have to execute "set_current_state(TASK_INTERRUPTIBLE)" before?
> Do I have to execute "set_current_state(TASK_RUNNING)" after?
> 
> I don't want to have to change this again so I really need to
> know. For instance, if I execute "set_current_state(TASK_INTERRUPTIBLE)"
> in version 2.4.24, it didn't hurt anything. In 2.6.1, there are
> conditions where schedule_timeout(0) doesn't return if another
> task is spinning "while(1) ; ". This is NotGood(tm).

As you have it, you may as well be calling schedule() inside that loop. 
You _have_ to be in state TASK_RUNNING, else you'll sleep forever.