[bug#29932] [PATCH v2 2/2] system: Rename operating-system-user-kernel-arguments to operating-system-kernel-arguments.

[Maxim Cournoyer]

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?

Maxim