[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29932: closed ([PATCH 0/2] Clean up operating-system-kernel-argument

From: GNU bug Tracking System
Subject: bug#29932: closed ([PATCH 0/2] Clean up operating-system-kernel-arguments.)
Date: Tue, 13 Jul 2021 11:57:02 +0000

Your message dated Tue, 13 Jul 2021 07:56:14 -0400
with message-id <878s2atokh.fsf_-_@gmail.com>
and subject line Re: bug#29932: [PATCH 0/2] Clean up 
has caused the debbugs.gnu.org bug report #29932,
regarding [PATCH 0/2] Clean up operating-system-kernel-arguments.
to be marked as done.

(If you believe you have received this mail in error, please contact

29932: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29932
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: [PATCH 0/2] Clean up operating-system-kernel-arguments. Date: Mon, 1 Jan 2018 14:22:00 +0100
Previously, the accessor for the field "kernel-arguments" in the structure
<operating-system> was called "operating-system-user-kernel-arguments".

The procedure "operating-system-kernel-arguments" made sure to add arguments
that made the system boot from a given device.

After some reflection I think I was mistaken in that.

It's nicer if the accessor is called "operating-system-kernel-argmuents"
and if the users just use "bootable-kernel-arguments" on their own in order to
amend them.

That's what this patch does.

Danny Milosavljevic (2):
  system: Inline operating-system-kernel-arguments.
  system: Rename operating-system-user-kernel-arguments to

 gnu/system.scm    | 19 ++++++++-----------
 gnu/system/vm.scm |  4 +++-
 2 files changed, 11 insertions(+), 12 deletions(-)

--- End Message ---
--- Begin Message --- Subject: Re: bug#29932: [PATCH 0/2] Clean up operating-system-kernel-arguments. Date: Tue, 13 Jul 2021 07:56:14 -0400 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hello,
> Danny Milosavljevic <dannym@scratchpost.org> writes:
>> Hi Ludo,
>>> I’m a bit lost: in my tree I don’t have
>>> ‘operating-system-boot-kernel-arguments’.  Is it still pending?
>> It's added by PATCH v2 1/2 from the series.  Didn't the second mail get 
>> through?
>>> Otherwise my only question is whether it’s a good idea to move away from
>>> the ‘user-’ convention.  On one hand, it’s the convention we also have
>>> for services (‘-user-services’ vs. ‘-services’), so it would be a good
>>> thing to remain consistent.  OTOH, what you propose is maybe clearer.
>>> 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?

There haven't been any further comments.



--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]