Re: [PULL] typesafe callbacks for kthread and stop_machine

[Andi Kleen <andi@firstfloor.org>]

On Fri, Aug 01, 2008 at 10:39:29AM +1000, Rusty Russell wrote:
> On Friday 01 August 2008 00:06:43 Andi Kleen wrote:
> > On Thu, Jul 31, 2008 at 02:52:35PM +1000, Rusty Russell wrote:
> > > Just the two places I look after.  And this time the conglomerate patch
> > > is included below for more random commentry.
> >
> > I must say I personally don't like the wrapper macros that you require
> > for each function that uses this. A wrapper macro has a large impact
> > on code readability because everyone following a call chain has
> > to do an additional grep/open file etc. step. I have my doubts not having
> > casts outweights that disadvantage.
> 
> Yes, but the benefits of using them everywhere is that they do become part of 
> the landscape.  "Oh, that's a typesafe callback, OK".

It's still an additional step slowing the reader/debugger/maintainer/etc.
down even when he recognizes that pattern.

> > I know that gcc has this funky transparent union extension that
> > glibc socket() uses to allow different address types without casts.
> > It has the advantage of not needing wrapper macros. Any chance of
> > using that instead? Or has that one been considered already and
> > discarded?
> 
> That's aimed at a slightly different case, where the function knows what types 
> it can get.  But that doesn't work for truly generic callbacks: the type is 
> completely controlled by the caller. ie. we want to allow whatever type 
> matches the arg.

In my experience often call backs are just numbers. Wouldn't we get a significant
part of the benefit by just allowing void * and unsigned long by default? (that
can be done with the gcc extension)

Or alternatively perhaps just teach sparse about this common pattern by adding
new annotations (new annotations would be fine for me, i just don't like
the additional indirection)

-Andi