Re: [RFC PATCH 5/5 v2] Convert tasklets to work queues

[Steven Rostedt]

On Sat, 2007-06-23 at 09:53 -0700, Andrew Morton wrote:
> > On Fri, 22 Jun 2007 14:20:56 -0400 Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> > This patch replaces the tasklet implementation with a work
> > queue implementation while keeping the tasklet API.
> > The API is still the same, and the drivers don't know that a
> > work queue is being used.
> 
> I still think this sucks: we end up with a fairly pointless-looking wrapper
> API which we wouldn't have put in the kernel except for messy legacy
> editing-is-too-hard reasons.  In an ideal world, it'd be better just to get
> in and do the hard work.

If I had all the hardware that tasklets touch, I'd start doing it. (look
for more patches from me that do this for the hardware I do have :-)

> 
> Anyway.  Please fix the many correct warnings which checkpatch.pl

I'll have to add a clean up patch. A lot of the output from that came
from me moving existing code.  So I'll have to clean up the existing
code first so that checkpatch.pl doesn't complain about it.  I prefer a
patch that moves code to do nothing but that, move code and not even add
clean ups to it.  So the simple solution is, add patch to clean up (will
do).

Also this:

   void tasklet_schedule(struct tasklet_struct *t)
   {
           WARN_ON_ONCE(!ktaskletd_wq);
           queue_work(ktaskletd_wq, &t->work);
   }

   EXPORT_SYMBOL(tasklet_schedule);


produces

   PATCH: tasklets-to-workqueues.patch:259:
   FILE: linux-2.6-test/kernel/tasklet_work.c:30:
   +EXPORT_SYMBOL(tasklet_schedule);


So I guess that blank line is not acceptable?
and should be:

   void tasklet_schedule(struct tasklet_struct *t)
   {
           WARN_ON_ONCE(!ktaskletd_wq);
           queue_work(ktaskletd_wq, &t->work);
   }
   EXPORT_SYMBOL(tasklet_schedule);

I'll fix that up.

> generates, reissue the patches with a decent overall changelog (this series
> had no rationale for the changes at all) and we'll see what happens.

Should I just put in the prologue from the first series, or slim it down
a bit so people don't need to read the whole thing every time? I can
just put in the stuff that's relevant and leave out the "history".

Thanks,

-- Steve


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/