linux-kernel - Re: [PULL] typesafe callbacks for kthread and stop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 1 Aug 2008 16:28:06 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Bert Wesarg <bert.wesarg@...glemail.com>,
	Tejun Heo <htejun@...il.com>
Subject: Re: [PULL] typesafe callbacks for kthread and stop_machine

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/