On Sat, 2006-12-02 at 14:05 +0000, Al Viro wrote:
> On Sat, Dec 02, 2006 at 01:59:30PM +0100, Thomas Gleixner wrote:
> > On Fri, 2006-12-01 at 17:21 +0000, Al Viro wrote:
> > > Now, there's another question: how do we get there? Or, at least, from
> > > current void (*)(unsigned long) to void (*)(void *)...
> >
> > I think the real solution should be
> >
> > void (*function)(struct timer_list *timer);
> >
> > and hand the timer itself to the callback. Most of the timers are
> > embedded into data structures anyway and for the rest we can easily
> > build one.
>
> Ewwwwwww....
>
> Let's not. It means more cruft in callbacks for no good reason.
What's the cruft ?
struct bla = container_of(timer, struct bla, timer); ???
> And more cruft in code setting it up, while we are at it.
Err, you remove the timer->data = (unsigned long) hackery. Why is this
adding cruft ?
I looked deeper into it. We have following timer usage:
- timers which don't use data at all - no change except for the callback
argument of the function.
- timers which point to the data structure which embedds them - only the
callback has to get a container_of()
- static single instance timers, which use .data as local storage for
some value. That can be done with a simple static variable near the
timer and using that variable instead of .data
- some rather seldom multi instance timers, which need then to become a
data structure.
> > > "A fscking huge patch flipping everything at once" is obviously not an
> > > answer; too much PITA merging and impossible to review.
> >
> > There are ~ 500 files affected and this is in the range of cleanups we
> > did recently at the end of the merge window already. I'd volunteer to
> > hack this up and keep the patch up to date until the final merge. I have
> > done that before and I'm not scared about it. The patches are a couple
> > of lines per file and I do not agree that this is impossible to review.
>
> I'd rather see that as patch series, TYVM. And no, it won't be a couple
> of lines per file with your variant.
It will. Just some random files:
arch/alpha/kernel/srmcons.c | 7 +++--
arch/arm/mach-pxa/lubbock.c | 7 +++--
arch/i386/kernel/tsc.c | 2 -
arch/i386/mach-voyager/voyager_thread.c | 2 -
arch/ia64/kernel/mca.c | 8 +++---
arch/ia64/kernel/salinfo.c | 2 -
arch/ia64/sn/kernel/mca.c | 2 -
arch/ia64/sn/kernel/xpc_channel.c | 3 --
arch/ia64/sn/kernel/xpc_main.c | 5 +++-
arch/mips/lasat/picvue_proc.c | 2 -
arch/mips/sgi-ip22/ip22-reset.c | 17 +++++++------
include/asm-ia64/sn/xpc.h | 2 -
> Anyway, I'm doing that series in my tree, will post when it's over...
Same here :)
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
