From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 2GZrFBpTf1+BQAAA0tVLHw (envelope-from ) for ; Thu, 08 Oct 2020 17:57:46 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id cHs2EBpTf18XEwAAB5/wlQ (envelope-from ) for ; Thu, 08 Oct 2020 17:57:46 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 64A3B94062D for ; Thu, 8 Oct 2020 17:57:40 +0000 (UTC) Received: from localhost ([::1]:40880 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kQaAd-00068j-5W for larch@yhetil.org; Thu, 08 Oct 2020 13:57:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59254) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kQa4E-00013B-04 for guix-patches@gnu.org; Thu, 08 Oct 2020 13:51:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:49778) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kQa4D-0003mr-Ll for guix-patches@gnu.org; Thu, 08 Oct 2020 13:51:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kQa4D-00067U-Ki for guix-patches@gnu.org; Thu, 08 Oct 2020 13:51:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#29932] [PATCH v2 2/2] system: Rename operating-system-user-kernel-arguments to operating-system-kernel-arguments. Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 08 Oct 2020 17:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29932 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Danny Milosavljevic Cc: 29932@debbugs.gnu.org, Ludovic =?UTF-8?Q?Court=C3=A8s?= Received: via spool by 29932-submit@debbugs.gnu.org id=B29932.160217945323510 (code B ref 29932); Thu, 08 Oct 2020 17:51:01 +0000 Received: (at 29932) by debbugs.gnu.org; 8 Oct 2020 17:50:53 +0000 Received: from localhost ([127.0.0.1]:33091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kQa44-000678-VB for submit@debbugs.gnu.org; Thu, 08 Oct 2020 13:50:53 -0400 Received: from mail-qt1-f193.google.com ([209.85.160.193]:36964) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kQa40-00066t-OM for 29932@debbugs.gnu.org; Thu, 08 Oct 2020 13:50:52 -0400 Received: by mail-qt1-f193.google.com with SMTP id s47so5826973qth.4 for <29932@debbugs.gnu.org>; Thu, 08 Oct 2020 10:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=OZ79y8W1VmglkE7RZ+c+1TVIhcG801YE+W1CGkNON4k=; b=Ru5v0489ceEK09OgZhI7t1SIhGLGkB5yDa99C9yJy8JJ8G4+Eq16S83Vraq//fDU/S FRUCttA5sjYblNjFaAObKrTW9EzHd4Xf7Meej/3Xh8PBRA+I2z5OmVKnIXs1XfNX1TWn xg2xsh2N3PH7xLIkD5cpqsO1TKnUAny7BWZWo7hJb+YqKOUC9Rq/hOSiKyI9hQOKo2Bj NuVzb7bXX8xfAN2057qPdOoMv/eRLh8e31rKqmUTCOjpvJ8dSJKWHckemxol/hZlx2yM 5yqTNX/MFSsvJaVIwI9MqqN9HHYex92ZtJyVpDYYqZEyvZEXvjK7UOLibXBeoW8Vqc/F Fl8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=OZ79y8W1VmglkE7RZ+c+1TVIhcG801YE+W1CGkNON4k=; b=s0H0DrqwsYh3WgRsWzypE6w34tYXXQiVGIrozcA0h6QB/LbieecoK6rc3MaKwVRvyn jJXvxqNqps6j7NW2gvQIu/kad+UabNs8iWGWG1zNH5RSx1IduCEJ30MQxCE1ZJlO4fIl ENr+JG4CIMfLJ0nSWl28DGK5p4TH0BOogPLEcyC1tpYprKIV4n/7yeywqzOE6qCOHgXq pRVSEtpaPRmBKPOmW8LqTx8cxkYPij8CvSLxK6q2/X3xVIQhoT36mzz9OIYssH3np0Uv Dt4EywpnKx579i6t6WmrLTnuBpuB93RGg+60Jrsp6cu7IHenMJtdWPwRVIalb4gKQ32R mtsA== X-Gm-Message-State: AOAM532I22rWY/mkwVoQfyQgwtCDsxI4uRB/TJEfQr39Biy5d4UCK9G4 /P5v65BE1IBSqvOf4kh9fYPTLoTDWVW3Xg== X-Google-Smtp-Source: ABdhPJzn5XIImeYE1tCuW2cFtY7weT75HkwRRXnWqbOoFkCaAsdjxOljE2TC83WDSEi6R9FDQ51XfQ== X-Received: by 2002:ac8:5a45:: with SMTP id o5mr3037637qta.182.1602179442673; Thu, 08 Oct 2020 10:50:42 -0700 (PDT) Received: from hurd (dsl-10-135-56.b2b2c.ca. [72.10.135.56]) by smtp.gmail.com with ESMTPSA id x21sm4507618qkb.78.2020.10.08.10.50.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2020 10:50:41 -0700 (PDT) From: Maxim Cournoyer References: <20180112105953.7198-1-dannym@scratchpost.org> <20180112110147.7305-1-dannym@scratchpost.org> <87o9lzqih9.fsf@gnu.org> <20180112154356.3fbd9177@scratchpost.org> Date: Thu, 08 Oct 2020 13:50:39 -0400 In-Reply-To: <20180112154356.3fbd9177@scratchpost.org> (Danny Milosavljevic's message of "Fri, 12 Jan 2018 15:43:56 +0100") Message-ID: <87k0w0txn4.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.0 (-) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=Ru5v0489; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: 0.09 X-TUID: RFzcUtjuTSwG Hello, Danny Milosavljevic writes: > Hi Ludo, > >> I=E2=80=99m a bit lost: in my tree I don=E2=80=99t have >> =E2=80=98operating-system-boot-kernel-arguments=E2=80=99. Is it still p= ending? > > It's added by PATCH v2 1/2 from the series. Didn't the second mail get t= hrough? > >> Otherwise my only question is whether it=E2=80=99s a good idea to move a= way from >> the =E2=80=98user-=E2=80=99 convention. On one hand, it=E2=80=99s the c= onvention we also have >> for services (=E2=80=98-user-services=E2=80=99 vs. =E2=80=98-services=E2= =80=99), so it would be a good >> thing to remain consistent. OTOH, what you propose is maybe clearer. >>=20 >> Thoughts? > > Yeah, I've split it into two patches because I actually got used to > operating-system-user-kernel-arguments by now (only a few days in). > We could only apply PATCH v2 1/2 and not apply PATCH v2 2/2 if we > wanted. > > In the end it comes down to whether we deem the existence > operating-system-boot-kernel-arguments an implementation detail or not > (whether the user would ever need to be aware of > operating-system-boot-kernel-arguments). We have to export > operating-system-boot-kernel-arguments because one thing in > gnu/system/vm.scm needs it - otherwise it would be very much an > implementation detail. > > Let's see what the others say. Two years later, here's what I have to say :-) I think it's nice, as a user, to be able to inspect the dynamically computed kernel arguments that Guix would use, as that can be used for debugging and gaining a better understanding (e.g., when passing an argument option that overrides one computed by Guix). If I followed this discussion correctly, currently we have: 1. operating-system-kernel-arguments which is a combination of dynamically computed arguments by Guix + the users arguments and 2. operating-system-user-arguments which are the users arguments themselves. It is proposed here to split this into: 1. operating-system-boot-kernel-arguments for the Guix-computed ones 2. operating-system-user-kernel-arguments remains unchanged Thus if the user wants to know what boot arguments their system will use, they'd have to append these two together. I think that two years have elapsed without touching this is perhaps an indication that it doesn't address any real problem :-). While it's good to attempt to clarify things, I'm afraid that changing this would confuse more that it'd help. As Ludovic pointed out, it'd also clash with the convention currently in use for services. What you do think? Maxim