Hi Jason, Thanks for your response! What you say makes perfect sense I'm basically looking at deferring work and was trying to get my head around tasklets. I guess a work queue is what I'm really looking for as I don't do interrupts, and like you said- pushing stuff to a fifo is not a good idea. I'm pretty sure that the rate at which I'll be deferring work is going to be more than the rate at which I'll be doing the actual work. Further the work itself might involve some block i/o in which case I'd need to sleep so I guess a work queue is the way to go? Thanks, -Joel On Sun, Oct 11, 2009 at 10:37 PM, Jason Nymble <jason.nymble@xxxxxxxxx> wrote: > > On 12 Oct 2009, at 6:24 AM, Joel Fernandes wrote: > >> Hi Friends, >> >> I have a question about tasklets: >> >> I understand that they are used to defer work during interrupt >> handling. What I don't understand is - how do they handle queuing of >> deferred work? >> Specially with tasklets, if a tasklet is re-scheduled before the >> previous scheduling of the same tasklet has a chance to run, then the >> tasklet is executed only once - not twice. But what if the work that >> the tasklet was supposed to do in these 2 instances were different and >> that its function was supposed to be passed 2 different structures? >> Shouldn't the tasklet be executed twice with these 2 structures? >> >> I know that work queues are there for that, but how do device drivers >> that use tasklets cope with the above? >> > > The tasklet_schedule() function takes only the struct tasklet_struct* as > parameter, so no extra information is sent to the tasklet function. That > struct is typically initialized only once, taking the function pointer and > one opaque value as parameters. The opaque value will typically point to a > device specific struct. The tasklet function needs to infer all the > information it requires just from the fact that it has been called (meaning > one or more interrupts occurred, if it was scheduled from an interrupt > handler), and e.g. read status registers etc. to determine what to do. You > _could_ probably push values onto an atomic list or fifo in the interrupt > handler and pop them off in a loop in the tasklet, but I don't think that is > the recommended way. It also seems from some lwn.net articles that tasklets > might be going away in the near future, to be replaced with threaded > interrupts. > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx > Please read the FAQ at http://kernelnewbies.org/FAQ > > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
