all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Karl Semich <fuzzytew@gmail.com>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Deterministic Library Calls when Building
Date: Sun, 20 Mar 2016 22:05:50 +0100	[thread overview]
Message-ID: <87d1qoc11t.fsf@gnu.org> (raw)
In-Reply-To: <CABnEbCFsKEa3VQ1QeMgRZqL2n-b+d1KPdMw1qiya6XW2zvmOaA@mail.gmail.com> (Karl Semich's message of "Sun, 20 Mar 2016 12:53:42 -0400")

Hello!

Karl Semich <fuzzytew@gmail.com> skribis:

> I'm pretty new at looking under the hood of linux, but I can imagine these
> approaches at least:
> - preload system library wrappers around key nondeterministic functions

Often, preloaded libraries are a bit fragile, in part because they need
to intercept a wide range of libc system call wrappers and to maintain
state.

An example is libfaketime, which people have tried to use in the context
of Debian’s reproducible builds effort.  In this particular case,
there’s the additional problem that tools that heavily rely on
timestamps, such as Make, break in unexpected ways in such environments.

> - replace /dev/*random with fakes (could be named pipes, dummy devices fed
> by modules, or just flat files!)

This one sounds like it could easily be implemented.

I think /dev/*random cannot be a flat file, because applications such as
test suites expect some sort of randomness, but it could be seeded with
a constant value.

In practice I don’t think we’ve ever identified a case where
/dev/*random was having a visible effect on build results.

> - replace system libraries with fullblown libraries with nondeterministic
> calls rewritten (could merge changes upstream, provide a flag)
> - create a kernel module which alters the behavior of the running kernel to
> be more deterministic
> - change the kernel itself to have a "deterministic mode" (could merge
> upstream)

In practice, the non-determinism issues we stumble upon are often either
“trivial” (e.g., a timestamp is stored somewhere), or super tricky
(e.g., result depends on thread/process scheduling.)

Because of that, I think that the changes that are easy to implement
would in fact be of little help, and that the changes that would be the
most helpful (e.g., deterministic scheduling) would take a lot of
effort and/or make the build environment much more complex.

But I may well be too pessimistic, and I think it’s good to investigate
how we could improve things!

Thanks,
Ludo’.

      parent reply	other threads:[~2016-03-20 21:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-20 10:04 Deterministic Library Calls when Building Karl Semich
2016-03-20 12:51 ` Thompson, David
2016-03-20 16:53   ` Karl Semich
2016-03-20 17:35     ` Jookia
2016-03-20 21:05     ` Ludovic Courtès [this message]

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=87d1qoc11t.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=fuzzytew@gmail.com \
    --cc=guix-devel@gnu.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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.