mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: Stephan Mueller <smueller@chronox.de>
Cc: "Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Theodore Ts'o" <tytso@mit.edu>, "Jörn Engel" <joern@logfs.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Linux Kernel Developers List" <linux-kernel@vger.kernel.org>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	"Ralf Baechle" <ralf@linux-mips.org>,
	dave.taht@gmail.com, "John Crispin" <blogic@openwrt.org>,
	andrewmcgr@gmail.com, "Thorsten Glaser" <tg@mirbsd.de>,
	sandyinchina@gmail.com
Subject: Re: [PATCH 2/5] CPU Jitter RNG: Enable compilation
Date: Tue, 4 Feb 2014 18:15:05 +0100	[thread overview]
Message-ID: <20140204171505.GC13928@order.stressinduktion.org> (raw)
In-Reply-To: <4270486.pLbfl66a7r@tauon>

Hi!

On Tue, Feb 04, 2014 at 05:53:39PM +0100, Stephan Mueller wrote:
> Am Dienstag, 4. Februar 2014, 17:39:57 schrieb Hannes Frederic Sowa:
> >On Tue, Feb 04, 2014 at 05:19:52PM +0100, Stephan Mueller wrote:
> >> Also, I consider the execution speed of the entropy collection is not
> >> really an issue because the RNG delivers random numbers at a
> >> comparatively high rate. Any other noise source feeding into random.c
> >> delivers data with far less speed.
> >
> >Compiling the kernel with -O0 could add some other problems, like
> 
> I thought with the given flag, I only compile the respective C file 
> without optimizations, but not the entire kernel. Am I wrong here?

That's correct.

But your file is pretty long and now someone tries to use a static inline
function from one of the included headers which itself does some tests with
compiletime_assert. In some cases compiletime_assert does generate a call to
an external function which does not exist in the kernel but will be folded away
if the compiler can check that the condition in the assert is always true. It
is expected that the linking process fails in case the assert could not be
shown valid.

So in case you add -O0 and you eliminate some optimizations the compiler may
not eliminate those calls to the undefined functions and thus you could always
get a linking error.

If you need to compile something with -O0 try to just put the non-optimizing
code into a seperate file and try to eliminate as much dependencies and
headers as possible.

> >e.g. not doing enough constant folding which could result in linking
> >errors. I guess it is not a problem currently though, but some of the
> >compile time checks depend on this (compiletime_assert and such).
> 
> How do you think that my folding code can cause linking errors?


I thought about the compiler not doing enough constant folding not
you. ;) The kernel is known to not always compile with optimization
levels below -O2.

Greetings,

  Hannes

  reply	other threads:[~2014-02-04 17:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-04 12:36 [RFC PATCH 0/5] CPU Jitter RNG Stephan Mueller
2014-02-04 12:39 ` [PATCH 1/5] " Stephan Mueller
2014-02-04 12:40 ` [PATCH 2/5] CPU Jitter RNG: Enable compilation Stephan Mueller
2014-02-04 13:39   ` Geert Uytterhoeven
2014-02-04 16:19     ` Stephan Mueller
2014-02-04 16:39       ` Hannes Frederic Sowa
2014-02-04 16:50         ` Hannes Frederic Sowa
2014-02-04 16:53         ` Stephan Mueller
2014-02-04 17:15           ` Hannes Frederic Sowa [this message]
2014-02-04 12:40 ` [PATCH 3/5] CPU Jitter RNG: integration with /dev/random Stephan Mueller
2014-02-04 12:41 ` [PATCH 4/5] CPU Jitter RNG: provide status proc files Stephan Mueller
2014-02-04 12:42 ` [PATCH 5/5] CPU Jitter RNG: add read/write sysctls Stephan Mueller
2014-02-04 17:08 ` [RFC PATCH 0/5] CPU Jitter RNG Theodore Ts'o
2014-02-04 19:06   ` H. Peter Anvin
2014-02-04 19:23     ` tytso
2014-02-04 19:39       ` Geert Uytterhoeven
2014-02-04 20:39         ` H. Peter Anvin
2014-02-04 21:46           ` Geert Uytterhoeven
2014-02-04 21:47             ` H. Peter Anvin
2014-02-10 21:07           ` Jörn Engel
2014-02-04 20:31     ` Stephan Mueller
2014-02-04 21:34       ` H. Peter Anvin
2014-02-04 21:43       ` Geert Uytterhoeven
2014-02-04 20:25   ` Stephan Mueller

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=20140204171505.GC13928@order.stressinduktion.org \
    --to=hannes@stressinduktion.org \
    --cc=andrewmcgr@gmail.com \
    --cc=blogic@openwrt.org \
    --cc=dave.taht@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=hpa@zytor.com \
    --cc=joern@logfs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=sandyinchina@gmail.com \
    --cc=smueller@chronox.de \
    --cc=tg@mirbsd.de \
    --cc=tytso@mit.edu \
    /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

all inboxes | Powered by JetHome®