Messages in this thread | | | Date | Sat, 2 Dec 2006 22:40:18 +0000 | From | Al Viro <> | Subject | Re: [RFC] timers, pointers to functions and type safety |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |