David Woodhouse wrote:
>
> andrewm@uow.edu.au said:
> > Nothing which sleeps for very long - mainly serial drivers which
> > queue a call to tty_hangup(), which immediately queues _another_
> > tq_scheduler call to do_tty_hangup (Why? Heaven knows).
>
> Not so much worried about that. More about how sensitive they would be to
> something _else_ causing the eventd thread to sleep for 'multiple seconds'
> before getting round to doing what they asked.
Ah. No, I don't think it would be polite to cause TTY hangup processing
to be deferred for this long. I'd suggest that the policy be "scheduled
tasks can't sleep". I guess kmalloc(GFP_KERNEL) is acceptable because
the system is already running like a dog if this sleeps.
> I really don't want to have to start using multiple eventd threads before
> 2.5, if at all. So I don't want to add the USB hub stuff unless the other
> queued tasks will be happy with that.
Some of these requirements could also be satisfied with a combination of
a timer_list and a tq_struct. When the timer fires, feed the tq_struct
into schedule_task.
Easy, except for the problem of killing the damn things off reliably. That
would require a bit of infrastructure. But it's the right thing for
netdriver media polling functions, for example.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Nov 23 2000 - 21:00:23 EST