On Sat, Dec 02, 2006 at 11:13:21PM +0100, Roman Zippel wrote:
> Hi,
>
> On Sat, 2 Dec 2006, Al Viro wrote:
>
> > > You need some more magic macros to access/modify the data field.
> >
> > Which is done bloody rarely. grep and you'll see... BTW, there are
> > other reasons why passing struct timer_list * is wrong:
> > * direct calls of the timer callback
>
> Why should that be wrong?
Need to arrange a struct timer_list?
> > * callback being the same for two timers embedded into
> > different structs
>
> That's done bloody rarely as well.
>
> > * see a timer callback, decide it looks better as a tasklet.
> > What, need a different glue now?
>
> What's wrong with changing the prototype? If you don't do it, the compiler
> will complain about it anyway.
How about "not having to change it at all"?
> > Look, it's a delayed call. The less glue we need, the better - the
> > rules are much simpler that way, so that alone means that we'll get
> > fewer fsckups.
>
> You have the glue in a different place, so what?
Where?
> The other alternative has real _practical_ value in almost every case,
> which I very much prefer. What's wrong with that?
Lack of any type safety whatsoever, magic boilerplates in callback instances,
rules more complex than "your callback should take a pointer, don't cast
anything, it's just a way to arrange for a delayed call, nothing magical
needed"?
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
