Re: [Nix-dev] /dev/shm inconsistency in chroot

2014-03-21 Thread Ludovic Courtès
Mark H Weaver m...@netris.org skribis:

 Shea Levy s...@shealevy.com writes:

 On 01/24/2014 05:16 AM, Sree Harsha Totakura wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1


 On 01/23/2014 08:56 PM, Mark H Weaver wrote:
 We should not inherit /dev from the host system at all, but rather
 create it from scratch with just the things we need.  IMO, that's
 the only truly proper solution.
 We can try creating a fixed set of device nodes, for example:
 /dev/null, /dev/random, /dev/urandom, /dev/sda etc.  Has anyone tried
 this before?

 Another option is to mount  a devtmpfs there, for systems which support it.

 The thing is, we don't actually want most of the system's devices to be
 in the build environment, do we?  These are all impurities.  I don't
 think we want /dev/sda, for example.

For the record, with
https://github.com/NixOS/nix/commit/3fd01b171a74d28dc8e48b9ee5f2d0e9a3915fb8,
the daemon creates /dev deterministically.  (This change landed in
guix-daemon with the latest ‘nix-upstream’ update.)

Ludo’.



Re: [Nix-dev] /dev/shm inconsistency in chroot

2014-01-24 Thread Shea Levy

On 01/24/2014 05:16 AM, Sree Harsha Totakura wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 01/23/2014 08:56 PM, Mark H Weaver wrote:

We should not inherit /dev from the host system at all, but rather
create it from scratch with just the things we need.  IMO, that's
the only truly proper solution.

We can try creating a fixed set of device nodes, for example:
/dev/null, /dev/random, /dev/urandom, /dev/sda etc.  Has anyone tried
this before?


Another option is to mount  a devtmpfs there, for systems which support it.


Sree
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlLiPZUACgkQO2+K8UPCHzvyuwCgpPH4ndRBqFkITqbPcQ1UN4Ws
JsYAniMrgj8mBvNMC7Jq1AkFv+bV/VUj
=DbCU
-END PGP SIGNATURE-
___
nix-dev mailing list
nix-...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev





Re: [Nix-dev] /dev/shm inconsistency in chroot

2014-01-24 Thread Ludovic Courtès
Shea Levy s...@shealevy.com skribis:

 On 01/24/2014 05:16 AM, Sree Harsha Totakura wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1


 On 01/23/2014 08:56 PM, Mark H Weaver wrote:
 We should not inherit /dev from the host system at all, but rather
 create it from scratch with just the things we need.  IMO, that's
 the only truly proper solution.
 We can try creating a fixed set of device nodes, for example:
 /dev/null, /dev/random, /dev/urandom, /dev/sda etc.  Has anyone tried
 this before?

 Another option is to mount  a devtmpfs there, for systems which support it.

Both options look good to me.  Using devtmpfs would be easier, but I
don’t see any documentation for it.  Are its contents really
deterministic?

Thanks,
Ludo’.



Re: [Nix-dev] /dev/shm inconsistency in chroot

2014-01-24 Thread Mark H Weaver
Shea Levy s...@shealevy.com writes:

 On 01/24/2014 05:16 AM, Sree Harsha Totakura wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1


 On 01/23/2014 08:56 PM, Mark H Weaver wrote:
 We should not inherit /dev from the host system at all, but rather
 create it from scratch with just the things we need.  IMO, that's
 the only truly proper solution.
 We can try creating a fixed set of device nodes, for example:
 /dev/null, /dev/random, /dev/urandom, /dev/sda etc.  Has anyone tried
 this before?

 Another option is to mount  a devtmpfs there, for systems which support it.

The thing is, we don't actually want most of the system's devices to be
in the build environment, do we?  These are all impurities.  I don't
think we want /dev/sda, for example.

 Mark



Re: [Nix-dev] /dev/shm inconsistency in chroot

2014-01-24 Thread Ludovic Courtès
Sree Harsha Totakura sreehar...@totakura.in skribis:

 On 01/24/2014 06:13 PM, Mark H Weaver wrote:
 Shea Levy s...@shealevy.com writes:
  Another option is to mount  a devtmpfs there, for systems which support 
  it.

 devtmpfs may give different devices on each machine and they may hinder
 our build reproducibility.

OK.

 The thing is, we don't actually want most of the system's devices to be
 in the build environment, do we?  These are all impurities.  I don't
 think we want /dev/sda, for example.

 Sure, I agree.  I propose we start enumerating commonly needed devices
 and create them.

Sounds good.

The major/minor device numbers may not be portable across OSes, which
may be a problem for Nix, so that code may need to be #ifdef’d.

 If in future, a package requires access to certain device while
 building (or during tests) we can include it in our list of created
 device nodes.

Yes, but keep in mind that we’re not going to change that often, because
it’s inconvenient.

Thanks,
Ludo’.



Re: [Nix-dev] /dev/shm inconsistency in chroot

2014-01-24 Thread Shea Levy

On 01/24/2014 04:17 PM, Ludovic Courtès wrote:

Sree Harsha Totakura sreehar...@totakura.in skribis:


On 01/24/2014 06:13 PM, Mark H Weaver wrote:

Shea Levy s...@shealevy.com writes:

Another option is to mount  a devtmpfs there, for systems which support it.

devtmpfs may give different devices on each machine and they may hinder
our build reproducibility.

OK.


The thing is, we don't actually want most of the system's devices to be
in the build environment, do we?  These are all impurities.  I don't
think we want /dev/sda, for example.

Sure, I agree.  I propose we start enumerating commonly needed devices
and create them.

Sounds good.

The major/minor device numbers may not be portable across OSes, which
may be a problem for Nix, so that code may need to be #ifdef’d.


Generally a good idea, but note that for now chroot is not enabled on 
non-Linux



If in future, a package requires access to certain device while
building (or during tests) we can include it in our list of created
device nodes.

Yes, but keep in mind that we’re not going to change that often, because
it’s inconvenient.

Thanks,
Ludo’.