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? How is that different from arranging some struct foo? Either you need a reference object anyway or a NULL pointer works in both cases. > > > * 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"? If it were a common operation, this might have some value... > > > 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? In SETUP_TIMER. > > 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"? I admit the compile check in SETUP_TIMER() is clever, but this way all the magic is in this place and is it really worth it? You're only adding _one_ extra typecheck for mostly simple cases anyway. The container_of() method is not new and is already well used in other places, it has real practical advantages, which would make the change actually worthwile. bye, Roman - 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/
