From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eRxln-0006hu-Ss for guix-patches@gnu.org; Thu, 21 Dec 2017 05:08:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eRxli-0004vp-Pt for guix-patches@gnu.org; Thu, 21 Dec 2017 05:08:07 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:36549) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eRxli-0004vl-La for guix-patches@gnu.org; Thu, 21 Dec 2017 05:08:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eRxli-0006oi-Ae for guix-patches@gnu.org; Thu, 21 Dec 2017 05:08:02 -0500 Subject: [bug#29409] Remove hugetlb control group on ARM32. Resent-Message-ID: From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <877euhtjkj.fsf@gmail.com> <87ind19pok.fsf@gmail.com> Date: Thu, 21 Dec 2017 11:07:40 +0100 In-Reply-To: (Tobias Geerinckx-Rice's message of "Thu, 21 Dec 2017 02:16:52 +0100") Message-ID: <87shc48kcz.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Tobias Geerinckx-Rice Cc: 29409@debbugs.gnu.org Hello! Tobias Geerinckx-Rice skribis: > Mathieu Othacehe wrote on 20/12/17 at 20:15: >> Mounting %control-groups fails on ARM32 platform because we build a >> kernel without LPAE support which implies hugetlb control group cannot >> be supported. > > What happens when the mount fails? At first glance, %control-groups > aren't needed-for-boot. Unfortunately, I'm not able to test it now: it's > all disgustingly hypothetical from here on. If =E2=80=98mount=E2=80=99 fails with EOPNOTSUPP, we could handle that spec= ifically, perhaps with an (optional? #t) flag on the file system or something. >> Like Debian we could have an ARMMP and ARMMP-LPAE kernel but the problem >> would still exists for ARMMP. >>=20 >> I'm not sure what do about, a workaround could be the ugly hack >> attached, WDYT ? > > So to me your patch implies that mounting the hugetlb cgroup is entirely > optional, and that no other (known) services will actually break if it's > not mounted. %control-groups are mounted as part of %base-file-systems, > about which the manual: > > -- Scheme Variable: %base-file-systems > These are essential file systems that are required on normal > systems, such as %PSEUDO-TERMINAL-FILE-SYSTEM and %IMMUTABLE-STORE > (see below.) Operating system declarations should always contain > at least these. > > In practice, %base-file-systems depends on more mounts than it probably > should, since some of them aren't essential and some can't even exist on > some platforms. That keeps things simple, and isn't a problem *if* > mounting optional file systems like %control-groups simply logs the > error and continues normally with the next mount. A bit dirty, perhaps, > but there are more places in file-systems.scm that feel that way to me. > > If the patch only serves to suppress such an error, I don't think it's > worth copying details of our kernel configurations around. > > If it fixes a broken boot, there's something... off about the way we > handle mounts. > > ...or maybe I am. Thoughts? =E2=80=98%base-file-systems=E2=80=99 is loosely defined and it=E2=80=99s a = moving target. Probably =E2=80=98%control-groups=E2=80=99 should be part of =E2=80=98%elog= ind-file-systems=E2=80=99 and not =E2=80=98%base-file-systems=E2=80=99, because I think it=E2=80=99s elog= ind that needs them. That would solve bare-bones-style configuration that doesn=E2=80=99t use elogind. It wouldn=E2=80=99t help for all things desktop, though. WDYT? > --- a/gnu/system/file-systems.scm > +++ b/gnu/system/file-systems.scm > @@ -21,6 +21,7 @@ > #:use-module (rnrs bytevectors) > #:use-module (srfi srfi-1) > #:use-module (guix records) > + #:use-module (guix utils) This is not great because (gnu system file-systems) is also used on the =E2=80=9Cbuild side=E2=80=9D, but (guix utils) would pull in (guix config),= which is configuration-dependent (it contains data that can vary from system to system): --8<---------------cut here---------------start------------->8--- scheme@(guile-user)> ,use(guix modules) scheme@(guile-user)> (source-module-closure '((guix utils))) $3 =3D ((guix utils) (guix config) (guix memoization) (guix profiling) (gui= x build utils) (guix build syscalls)) scheme@(guile-user)> (source-module-closure '((gnu system file-systems))) $4 =3D ((gnu system file-systems) (guix records) (gnu system uuid)) --8<---------------cut here---------------end--------------->8--- Thanks, Ludo=E2=80=99.