From: Ingo Molnar <mingo@elte.hu>
To: David Woodhouse <dwmw2@infradead.org>
Cc: torvalds@linux-foundation.org, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] intel-iommu: fix build with CONFIG_BRANCH_TRACER=y
Date: Tue, 7 Apr 2009 14:57:26 +0200 [thread overview]
Message-ID: <20090407125726.GA31372@elte.hu> (raw)
In-Reply-To: <1239108263.22733.492.camel@macbook.infradead.org>
* David Woodhouse <dwmw2@infradead.org> wrote:
> On Tue, 2009-04-07 at 14:14 +0200, Ingo Molnar wrote:
> > Well, i consider it a feature that it flags weird if (x, y)
> > constructs: and yes, these iterators you introduced, while they are
> > legit C, definitely count as 'weird'. If regular code was doing it,
> > not a loop abstraction, i'd call it non-obvious and borderline
> > broken straight away.
> >
> > We should _never ever_ put comma statements into if ()
> > constructs without a _really_ good reason - and if yes, we can
> > flag that we know what we are doing, via extra parentheses.
>
> I disagree. I don't think we should be declaring valid C syntax as
> 'off limits', however rare it is.
>
> _Especially_ if it only actually fails with a fairly esoteric
> config option set. That's just asking for build breakage.
It failed within 10 minutes of testing for me. And i did not say
'off limits', i said 'needs a second look and a i-know-what-i-am
doing flag'.
Anyway, we apparently disagree about what constitutes acceptable
code and what not. I am more cautious about "weird looking"
constructs, and for a good reason: often a 'hm, this looks a bit
weird' sub-conscious feeling is the only sign we have of a serious
bug in the making.
So making code not look weird and teaching people to not use weird
looking patterns in usual code is a prime goal - at least to me.
Does such an approach limit the C language? Yes, of course it does,
that's the whole point. You appear to be more of the "if it's valid
C it's fine" camp.
> > and if yes, we can flag that we know what we are doing, via
> > extra parentheses.
>
> That's hardly much of a barrier. The requirement to sprinkle
> gratuitous-looking extra parentheses around the place really isn't
> going to give us much of a _benefit_ in return for the build
> breakage.
The thing is, the branch-tracer might be even more weird than your
iterator (it certainly is, and we might even remove it if it's
causing undue problems), but it has been upstream for some time
already and it is certainly useful for certain types of
difficult-to-analyze codepaths.
Also, it is not breaking the build currently [with any given
combination of weird .config combos] - so there's no 'sprinking'
anywhere except your arguably under-tested iterator ;-)
Ingo
next prev parent reply other threads:[~2009-04-07 12:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1238839639.3560.37.camel@macbook.infradead.org>
2009-04-07 5:37 ` [GIT *] intel-iommu updates for 2.6.30 (second batch) Ingo Molnar
2009-04-07 5:42 ` Ingo Molnar
2009-04-07 5:52 ` David Woodhouse
2009-04-07 5:44 ` David Woodhouse
2009-04-07 5:48 ` Ingo Molnar
2009-04-07 5:52 ` Ingo Molnar
2009-04-07 6:04 ` David Woodhouse
2009-04-07 6:15 ` Ingo Molnar
2009-04-07 6:18 ` David Woodhouse
2009-04-07 8:49 ` Ingo Molnar
2009-04-07 9:02 ` [PATCH] intel-iommu: fix build with CONFIG_BRANCH_TRACER=y Ingo Molnar
2009-04-07 11:33 ` David Woodhouse
2009-04-07 12:14 ` Ingo Molnar
2009-04-07 12:44 ` David Woodhouse
2009-04-07 12:57 ` Ingo Molnar [this message]
2009-04-07 13:14 ` David Woodhouse
2009-04-07 14:54 ` Linus Torvalds
2009-04-07 14:59 ` Linus Torvalds
2009-04-07 15:12 ` Ingo Molnar
[not found] ` <f73f7ab80904071540w3d298c3bh386b46d5685f746e@mail.gmail.com>
2009-04-07 22:42 ` Kyle Moffett
2009-04-07 14:50 ` Linus Torvalds
2009-04-07 6:39 ` [GIT *] intel-iommu updates for 2.6.30 (second batch) Ingo Molnar
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=20090407125726.GA31372@elte.hu \
--to=mingo@elte.hu \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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