BLS: say that initrd may be split at whitespace for compat

[keszybz]

A path is not allowed to contain whitespace (only ASCII upper and lower case characters, digits, "+", "-", "_" and "." per the first section), so we know that a space cannot occur in the value. But unfortunately, this is an easy mistake to make. We made the situation worse by allowing other keys to contain whitespace-separated paths, e.g. 'devicetree-overlay' is defined as "multiple overlays are separated by spaces and applied in the same order as they are listed." So it's easy to try to apply the same pattern in other places. Also, the implementation that was done for grub2 allowed multiple paths to be specified. It is certainly confusing if we say that

  initrd /some/path/initrd /some/path/extra

is not a valid. If instead we were to correctly understand that the user meant two different initrds and emit a warning, our behaviour would be more robust and user-friendly.

C.f. systemd/systemd#38834
https://bugzilla.redhat.com/show_bug.cgi?id=2323348
https://lists.fedoraproject.org/archives/list/[email protected]/message/AYB4VHQ5K6CEV4NYCK2QTZB2OEAIJMP7/

[behrmann]

This begs the question "to increase compatibility with what?", since making this implementation-defined, might lead to more incompatibility between different implementations. Judging from the rationale in the commit message, it's to be more compatible with the semantics of other keys, but that's not clear form the text here alone.

I also think that this should note the preferred behaviour, so that implementations may converge on it.

[keszybz]

I don't think it makes sense to say "increase compatibility with confused users"… What about "To increase robustness" ?

I also think that this should note the preferred behaviour, so that implementations may converge on it.

OK. So maybe this should say "an implemention should split that path at whitespace".

[behrmann]

I think that's good and goes well with "to increase robustness".

[keszybz]

Updated.

[poettering]

urks. so iuc there are exactly to stanzas right now where it makes sense to allow multiple values for a single entry: the initrd one and the devicetree-overlay one. we really should unify the wording for them.

I generally think the way to go for all this is allowing multiple specifications of the line type, and refuse multiple parameters on the same line. I am not sure the devicetree-overlay line even has a single implementation (we don't support it do we?), hence i think we can even change that for that stanza right now.

[poettering]

let me rephrase this. there are two (and a half) bls stanzas where multiple use in the same file makes sense:

1. initrd
2. devicetree-overlay
3. options [i'll count this as the half one]

I think we really should define a common story here how they are supposed to appear, i.e. either with space separated arguments, or in multiple whole lines, each starting with the stanza name. Regardless what we do, we should support the same syntax for all three stanzas.

Right now, "devicetree-overlay" the spec suggests that multiple use should be done via space separated parameters. For "options" the spec says that multiple "options" stanza is fine, and of course, everyone knows that space separation works too. For "initrd" we suggest multiple stanza syntax, do not define space-separated syntax.

Or in other words: it's all over the place. We should clean that up, and normalize this. Given that both syntaxes are already sufficiently established I guess the ship of sticking to one of them has already sailed. Hence, I guess we should allow both. Or in other words we should declare that a type1 drop-in with this:

…
option foo
option bar
initrd /quux
initrd /waldo
devicetree-overlay /bimpf
devicetree-overlay /bumpf
…

is fully equivalent to:

…
option foo bar
initrd /quux /waldo
devicetree-overlay /bimpf /bumpf
…

any chance you can reword the spec like that, and ideally use the same wording for all three stanzas?