LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@mindspring.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: Linux kernel mailing list <linux-kernel@vger.kernel.org>,
	rth@twiddle.net
Subject: Re: [PATCH] Stop making "inline" imply forced inlining.
Date: Fri, 19 Jan 2007 12:39:37 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0701191228200.25140@CPE00045a9c397f-CM001225dbafb6> (raw)
In-Reply-To: <20070119172542.GO9093@stusta.de>

On Fri, 19 Jan 2007, Adrian Bunk wrote:

> On Fri, Jan 19, 2007 at 11:56:30AM -0500, Robert P. J. Day wrote:
> >
> >   Remove the macros that define simple "inlining" to mean forced
> > inlining, since you can (and *should*) get that effect with the
> > CONFIG_FORCED_INLINING kernel config variable instead.
>
> NAK.
>
> I don't see any place in the kernel where we need a non-forced
> inline.

that's not the point.  the point is that, as it stands now, the build
is *broken* in three ways.

first, it's broken because declaring something simply as "inline"
*forces* it to be inlined, which flies in the face of historical
convention and is more than a little misleading.

second, it's broken because both the use of
"__attribute__((always_inline))" all over the place and the
CONFIG_FORCED_INLINING kernel config option imply that you indeed have
a choice, when you clearly *don't*.  quite simply, you can play with
that kernel config option or splash the "always_inline" attributes
around all you want and, unbeknownst to you, none of that is making
the *slightest* bit of difference.  that is the very *definition* of a
"broken" build.

and, finally, you claim that you "don't see any place in the kernel
where we need a non-forced inline."  i have already posted an alpha
header file that claims (rightly or wrongly) to need that freedom.
Q.E.D.

> We have tons of inline's in C files that should simply be removed -
> let's do this instead.

that may be a better idea, but it doesn't address the current
brokenness.

i'm willing to believe that this patch has zero chance of going
anywhere.  but if you want to reject it, at least be honest about it.
don't say, "there's no problem here."  instead, say, "yes, the build
is broken but we don't feel like doing anything about it."

rday

  reply	other threads:[~2007-01-19 17:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-19 16:56 Robert P. J. Day
2007-01-19 17:25 ` Adrian Bunk
2007-01-19 17:39   ` Robert P. J. Day [this message]
2007-01-19 18:40     ` Adrian Bunk

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=Pine.LNX.4.64.0701191228200.25140@CPE00045a9c397f-CM001225dbafb6 \
    --to=rpjday@mindspring.com \
    --cc=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rth@twiddle.net \
    --subject='Re: [PATCH] Stop making "inline" imply forced inlining.' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).