public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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