Normally URLs work the way that a relative path is relative to the originating document, with no special prefix. This : is rather ugly… If we have a separate uki-url key, then we don't need specify :. In fact, it'd be better to follow normal HTTP rules, and allow /some/path to refer to the an absolute path on the same server, foo/bar to refer to a path relative to the bootloader (our "originating document"), and http://some.address/full/url for full URLs.

the only reason i did the : thing is that I am talking about url here, not http. So this could in theory be anything, i.e. nvmet:, iscsi: nfs: or ftp: or even file: or anyhting else even.

But if you read the rfc spec you'll find that they generically only say <scheme>:<scheme specific part> as syntax, which makes it really hard to distinguish simple file names from full urls... i.e. is "nvmet:192.168.1.1" a file or an url? it's not that obvious to me...

for web stuff, they know they know much better what to look for in an url than what we do, i.e. they know it's pretty much about http:// and https://, so they can look for that. but for boot stuff it would suck to build such a db of url prefixes, I doubt it's realistic.

hence i opted for the : prefix, because the URI RFC says the scheme must be ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ), i.e. not :. And thus there is no ambiguity anymore, for any string we can clearly say "this should be interpreted as URI" and "that should be interpreted as filename".

does that make sense?

Since the RFC is referenced here, I wonder, does it need both keys uki and uki-url? Since the URIs have a scheme, uki-url file:///fooos/bar.efi should have the same semantics as above, no? One could document that without a scheme prefixed file:// is implied.

file:// is weird, it has a "host" anchor which noone knows what it's relative to. the type 1 stanzas such as linux/initrd/efi so far made very clear that they are relative to the ESP or the partition the snippets are placed in. you cannot really express that with file://.

the reason i split uki from uki-url is mostly for the same disambiguation reasons described above, also i figured it's a good idea to distinguish "network boot" from "regular boot" with a very high-level construct, i.e. via a stanza. or to say this differently, if we'd shoehorn uri support into uki, then people would want it for initrd and linux and efi too, and I'd really like to avoid that. or with other words: i think it should be a property of an entry as a whole whether it is network based, not of the individual files listed therein, if that makes sense?

I'm fine with that reasoning.

My implicit assumption was, that file:// in this context would anchor at the ESP like the other ones, since everything else would be confusing, i.e. seeing the firmware as a host on its own, with the ESP as its root.

When people would ask for network support for linux, initrd and friends, I'd politely point them to ipxe. :)

IPXE supports specifiers in URLs e.g.

#!ipxe
initrd http://myserver.com/initrd?uuid=${uuid}&mac=${mac:hexhyp}
kernel https://myserver.com/vmlinuz?uuid=${uuid}&mac=${mac:hexhyp}

which is great in datacenters as you can serve specific images for specific servers dynamically and assign roles to specific servers in your control plane and then just reboot to re-provision
e.g. with https://matchbox.psdn.io/matchbox/

Can we do something similar here?

So a specifier for the machine-id and maybe the SMBIOS UUID (Though perhaps those are the same when SMBIOS UUID is available?)

Fits in nicely with: systemd/systemd#32086 because then the machine id and the SMBIOS UUID match

Though I guess if you already have a machine-id stanza in your boot entry you might as well manually copy it into the uki-url field as well...