Subject: [alpine-devel] Re: [alpine-aports] [PATCH] main/mkinitfs: backport cryptdiscards patch

From: Natanael Copa <[email-masked]>
Date: Fri, 16 Jun 2017 18:11:42 +0200

On Wed, 14 Jun 2017 23:44:34 +0200
Sören Tempel <[email-masked]> wrote:

> On 14.06.17, Natanael Copa wrote:
> > What do you think? Should we go for:
> > 
> >   cryptroot=$device cryptdm=$dmname cyptdiscards=yes cryptheader=$header cryptoffset=$offset
> > 
> > or should we do:
> > 
> >   cryptdevice=$device:$dmname:allow-discards cryptkey=$header:$offset  
> 
> Honestly I don't have a strong opinion on this. I believe the latter is
> harder to read and besides we would break backwards compatibility if we
> would switch to this scheme.
> 
> Do you have an opinion on this? Would you like to switch to the latter?

Does anybody on alpine-devel have opinion on what the boot args should be for LUKS devices?

-nc

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Sören Tempel <[email-masked]>
Date: Thu, 22 Jun 2017 17:48:36 +0200

> Does anybody on alpine-devel have opinion on what the boot args should

Doesn't seem to be the case. How about merging this into the mkinitfs
repository without backporting it for now? We can still change the name
of the kernel parameters later on.

Cheers,
Sören

---

---

From: Sören Tempel <[email-masked]>
Date: Fri, 14 Jul 2017 16:59:55 +0200

Ping?

---

---

From: 7heo <[email-masked]>
Date: Mon, 17 Jul 2017 10:46:40 +0200

>> of the kernel parameters later on.

Hey there,

Sorry for the lag, I couldn't answer in Friday and then the week end got 
in the way.

However, I prefer the separated-variables way, and by far. Here is the 
reasoning:

- The parsing would happen in shell (as opposed as in the initfs binary) 
and I don't think doing unnecessary (for appearance only) text parsing 
in shell is the sane way to go.

- Using ':' (or anything else really) as separator is assuming that this 
character isn't used in any identifier in the list. In the past, present 
and future. For any of those identifiers, ever. And really, we cannot 
assume that.

- Separating variables with their name is way more explicit and way less 
magic than establishing an arbitrary order and relying on the users to 
read the documentation on what a variable does, and in what order.

- Having multiple variables grouped where it is technically incorrect 
will be misleading and confusing, teaching newcomers the wrong lessons.

* * *

Long story short, I do not think that the cost (purely visual) of having 
the variables separated in the configuration file is worth the technical 
effort and technical risk of concatenating them. KISS.

HTH
7heo

---