linux-kernel - Re: [PATCH] dmaengine: edma: fix build without CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 04 Nov 2015 11:29:01 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Peter Ujfalusi <peter.ujfalusi@...com>,
	Vinod Koul <vinod.koul@...el.com>,
	Sekhar Nori <nsekhar@...com>, linux-kernel@...r.kernel.org,
	Kevin Hilman <khilman@...prootsystems.com>,
	dmaengine@...r.kernel.org, Dan Williams <dan.j.williams@...el.com>,
	linux-omap@...r.kernel.org
Subject: Re: [PATCH] dmaengine: edma: fix build without CONFIG_OF

On Wednesday 04 November 2015 11:05:54 Peter Ujfalusi wrote:
> > 
> > I think that would be less readable, and gives no compile-time coverage
> > to the contents of the edma_tc_set_pm_state function.
> 
> Hrm, if the compiler knows that there is no need to compile the code after the:
> if (!IS_ENABLED(CONFIG_OF) || !tc)
> when OF is disabled, then it does not give more compile coverage then have
> empty inline function in case of !OF.

No, the way it works (simplified but close enough here) is that gcc parses
all the source code first and throws warnings or errors for everything that
looks wrong to it, and only later throws out all code that it knows is never
used before emitting the object code.

The difference to the #ifdef is that the preprocessor here throws out all
disabled code before it gets parsed, so we don't get warnings for it.

> Not sure about it, but if we disable all optimization in gcc, then we might
> get the same missing symbol?

It's impossible to build the kernel with inlining disabled, because we
rely on the same kind of optimization in lots of places.

> > The effect is the same, so I'd rather stay with my version.
> 
> I'm fine with both. It is up to Vinod to decide which one he prefers (I prefer
> the #if #else #endif version).
> 
> Anyways:
> Acked-by: Peter Ujfalusi <peter.ujfalusi@...com>

Thanks!

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/