public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Dipankar Sarma <dipankar@in.ibm.com>,
	linux-kernel@vger.kernel.org, shemminger@osdl.org,
	manfred@colorfullife.com, bunk@stusta.de
Subject: Re: [RFC,PATCH 2/4] Deprecate synchronize_kernel, GPL replacement
Date: Mon, 4 Apr 2005 14:13:36 -0700	[thread overview]
Message-ID: <20050404211335.GF1297@us.ibm.com> (raw)
In-Reply-To: <200504040026.52101.arnd@arndb.de>

On Mon, Apr 04, 2005 at 12:26:50AM +0200, Arnd Bergmann wrote:
> On Sünndag 03 April 2005 20:50, Paul E. McKenney wrote:
> > I couldn't find any way to suppress the "deprecated" warning that is
> > generated by the "&sym" in the last line of the __EXPORT_SYMBOL()
> > macro.  Anyone know a way of doing this?  There doesn't seem to me
> > to be any point to giving the warning on the EXPORT_SYMBOL() -- and
> > it does clutter up compiler output with useless "deprecated" warnings.
> 
> You can define an inline function that is marked __deprecated and calls
> the exported function:
> 
> extern void __synchronize_kernel(void);
> static inline __deprecated synchronize_kernel(void)
> {
>         __synchronize_kernel();
> }
> ===
> void __synchronize_kernel(void)
> {
>         synchronize_rcu();
> }
> EXPORT_SYMBOL(__synchronize_kernel);

Cute!  This would indeed deprecate synchronize_kernel() everywhere, while
at the same time avoiding a "deprecated" warning on any EXPORT_SYMBOL().
However, it would provide a new symbol, __synchronize_kernel(), that
could be called from any module, but with no "deprecated" warning.

> You could even make __synchronize_kernel() static to let it only be used
> by modules, but that might create some confusion about the interface.

-That- is an interesting trick!

Thinking about this more, it seems like getting the warning in modules
but not in mainline is OK.  If uses creep into the mainline, we can always
just change them when they are noticed.  In the worst case, it is still
easy to simply update them when we remove synchronize_kernel() next April,
right?

						Thanx, Paul

  reply	other threads:[~2005-04-04 21:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-03  6:21 [RFC,PATCH 2/4] Deprecate synchronize_kernel, GPL replacement Paul E. McKenney
2005-04-03  8:56 ` Dipankar Sarma
2005-04-03 18:50   ` Paul E. McKenney
2005-04-03 22:26     ` Arnd Bergmann
2005-04-04 21:13       ` Paul E. McKenney [this message]
2005-04-03 14:11 ` Michael Ellerman
2005-04-03 18:54   ` Paul E. McKenney

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=20050404211335.GF1297@us.ibm.com \
    --to=paulmck@us.ibm.com \
    --cc=arnd@arndb.de \
    --cc=bunk@stusta.de \
    --cc=dipankar@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=shemminger@osdl.org \
    /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