From: Rusty Russell <rusty@rustcorp.com.au>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, Jeff Garzik <jeff@garzik.org>
Subject: Re: [PATCH 5/5] typesafe: TIMER_INITIALIZER and setup_timer
Date: Mon, 10 Mar 2008 12:07:19 +1100 [thread overview]
Message-ID: <200803101207.20151.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20080306104034.GB27894@ZenIV.linux.org.uk>
On Thursday 06 March 2008 21:40:35 Al Viro wrote:
> extern void decay_to_pointer(void const volatile *);
> #define check_callback_type(f,x) (sizeof((0 ? decay_to_pointer(x),(f)(x) :
> (void)0), 0)) #define __setup_timer(timer, func, arg) \
> do { \
> struct timer_list *__timer = (timer); \
> __timer->function = (void (*)(unsigned long))(func); \
> __timer->data = (unsigned long)(arg); \
> (void)check_callback_type(func, arg); \
> } while(0)
Thanks for that snippet; it's much more complete than the last one I found.
I especially like the handling of const- and volatile-taking callback fns.
My version is uglier, pasted below.
There are three problems I see here. First, the lack of warning for "void
intfn(int); DECLARE_TIMER(t, intfn, 0);", but that's relatively minor.
Second, the change of all the users is just churn, with cast_if_type() it can
be done over the next couple of years, if ever.
Worst, I can't see a way to apply your technique in general, for
non-void-returning functions (eg. interrupt handlers).
Here's the typesafe_cb () helper function from ccan (there are also
typesafe_cb_preargs and postargs for callbacks with extra args):
/* Doesn't handle const volatile, but can be added. */
#define typesafe_cb(rettype, fn, arg) \
cast_if_type(cast_if_type(cast_if_type((fn), \
rettype (*)(const typeof(arg)), \
rettype (*)(void *)), \
rettype (*)(volatile typeof(arg)), \
rettype (*)(void *)), \
rettype (*)(typeof(arg)), \
rettype (*)(void *))
> PS: apologies for missing your previous mail; ETOOBIGMBOX ;-/
That's fine, happens to all of us. I was a little disappointed to return from
holiday to discover that either your work or mine hadn't been merged tho :)
Cheers,
Rusty.
next prev parent reply other threads:[~2008-03-10 1:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-04 12:11 [PATCH 0/5] typesafe callbacks Rusty Russell
2008-02-04 12:14 ` [PATCH 1/5] cast_if_type: allow macros functions which take more than one type Rusty Russell
2008-02-04 12:16 ` [PATCH 2/5] typesafe: Convert stop_machine Rusty Russell
2008-02-04 12:17 ` [PATCH 3/5] typesafe: kthread_create and kthread_run Rusty Russell
2008-02-04 12:18 ` [PATCH 4/5] typesafe: request_irq and devm_request_irq Rusty Russell
2008-02-04 12:19 ` [PATCH 5/5] typesafe: TIMER_INITIALIZER and setup_timer Rusty Russell
2008-02-04 14:57 ` Al Viro
2008-02-05 3:41 ` Rusty Russell
2008-03-05 2:55 ` Rusty Russell
2008-03-06 10:40 ` Al Viro
2008-03-10 1:07 ` Rusty Russell [this message]
2008-03-10 2:03 ` Al Viro
2008-03-10 3:42 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200803101207.20151.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox