From mboxrd@z Thu Jan  1 00:00:00 1970
From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Subject: Re: [PATCH] Build sandbox support etc. unconditionally on Linux.
Date: Wed, 07 Sep 2016 10:14:53 +0200
Message-ID: <87fupcqg76.fsf@gnu.org>
References: <07494b64-bc74-6b7f-166f-14eeff2f196b@gmail.com>
	<87bn10wmka.fsf@netris.org>
	<d3217310-7097-261f-d2cc-9c15e5458d86@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55935)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1bhY0e-0006BW-0y
	for guix-devel@gnu.org; Wed, 07 Sep 2016 04:15:04 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1bhY0Y-0002JU-0b
	for guix-devel@gnu.org; Wed, 07 Sep 2016 04:15:02 -0400
In-Reply-To: <d3217310-7097-261f-d2cc-9c15e5458d86@gmail.com> (Manolis
	Ragkousis's message of "Wed, 10 Aug 2016 22:07:21 +0300")
List-Id: "Development of GNU Guix and the GNU System distribution."
	<guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/guix-devel/>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=subscribe>
Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org
Sender: "Guix-devel" <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
To: Manolis Ragkousis <manolis837@gmail.com>
Cc: guix-devel <guix-devel@gnu.org>

Hello Manolis!

Manolis Ragkousis <manolis837@gmail.com> skribis:

> On 08/10/16 20:39, Mark H Weaver wrote:
>>
>> I'm very reluctant to apply this patch.  In general, it's preferable to
>> rely on autoconf to test for individual features, rather than testing
>> for particular kernels by name.  It seems to me that this patch will
>> hinder portability to other kernels.
>>
>> I'd be inclined to return to the approach you were proposing before
>> discovering this upstream patch.  I'll take a look at it soon.
>>
>> What do you think?
>
> Well the other solution will be to break the CHROOT_ENABLED into smaller
> macros, depending on what we check.  If you think this is a better
> solution then okay with me.
>
> Locally I broke CHROOT_ENABLED into
>
> #define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H &&
> defined(MS_BIND) && defined(MS_PRIVATE)
> #define CLONE_ENABLED defined(CLONE_NEWNS)
> #if defined(SYS_pivot_root)
> #define pivot_root(new_root, put_old) (syscall(SYS_pivot_root, new_root,
> put_old))
> #endif

That sounds preferable, or maybe just avoid CHROOT_ENABLED altogether?

> And maybe we should rename CHROOT_ENABLED into SANDBOX_ENABLED or
> something similar to better describe its purpose.

I=E2=80=99d rather not (Nix made this change, but that=E2=80=99s largely be=
cause OS=C2=A0X
has a similar feature called =E2=80=9Csandbox=E2=80=9D, so they used this n=
ame in the
code.)

Ludo=E2=80=99.