> In case of using task queues for deferred processing in an interrupt
> handler (isr), A task statically defined as type tq_struct is usually
> used to queue for dpc by the call to queue_task().
...
> go in an infinite loop. How do you guarantee in an isr that the
> previously queued task is already scheduled ?
I did this very thing using the atomic bit operations to test if the bottom
half needs to be scheduled. Something like this in your ISR:
...
/* Check to see if bh needs to be scheduled */
if (set_bit(0, &bh_scheduled) == 0) {
/* clear old struct, fill in fields */
queue_task( &bh_task, &tq_immediate );
}
...
And then in the bottom half, when the work is done I do a
clear_bit(0, &bh_scheduled) to indicate it is safe to re-queue the task.
> And obviously, allocating memory for a tq_struct in an isr is not
> recommended.
Right, although you could do it with GFP_ATOMIC, it would be sloppy and
failure-prone.
> Or should I maintain a list of tq_struct structures initially allocated ,
> and pick up an unused one everytime an interrupt occurs.? How is
I tried this method as well, and it works fine too. But you can avoid the
extra memory consumption and make the routine even faster by not scheduling
the redundant task in the first place. You also avoid the risk of running
out of the free-list of tq_structs.
> I cannot use bottom halves as I intend the driver to be a dynamically
> loadable.
Using tq_immediate essentially is a bottom half when IMMEDIATE_BH is used
as your bottom half.
-bp
-- B. James Phillippe . bryan@terran.org Software Engineer, WGT Inc. . http://www.terran.org/~bryan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/