boot: bring your own boot sequence#5470
Conversation
|
This now includes an updated (I'll look into CI failure in a bit.) |
eb49a07 to
9e2a00f
Compare
joemfb
left a comment
There was a problem hiding this comment.
Sorry for the absurd delay @Fang-!
This all looks reasonable. I've picked some nits the C changes, and noted a couple refcounting issues. I've only minimally reviewed the hoon so far, mostly to highlight some questions about the new move/message types that have been introduced.
We'll need to go over which ovums are included in the pill by default, and which (if any) props are downloaded by default. I suspect will want a set of default URL props, and a commandline flag to turn them off.
| [%park des=desk yok=yoki ran=rang] :: synchronous commit | ||
| [%perm des=desk pax=path rit=rite] :: change permissions | ||
| [%pork ~] :: resume commit | ||
| [%prep lat=(map lobe blob)] :: prime blob store |
There was a problem hiding this comment.
I wonder if this should just be (list blob) so that %clay will recompute hashes.
There was a problem hiding this comment.
Discussed this with @philipcmonk, just leaving it as a map for now.
| u3_atom jam = _king_get_atom(url_c); | ||
| mor = u3nc(u3ke_cue(jam), mor); | ||
| c3_free(url_c); | ||
| } |
There was a problem hiding this comment.
If we're going to be requesting several more files over the network, it'll probably be important to flesh out _king_get_atom() with retry logic, better error handling, &c.
There was a problem hiding this comment.
I added some dumb retry logic. Not sure what else you were imagining with better error handling here. Probably not worth following redirects or w/e?
joemfb
left a comment
There was a problem hiding this comment.
There's a couple things here I may still want to tweak, especially the behavior around default props. But I'm going to merge this out of band (don't worry about the conflicts), so I'll address those elsewhere.
Thanks for pulling this together!
Adds support for --prop-file, --prop-url and --prop-name, which let one augment the boot sequence of a ship with additional events. Back-ports the vere changes from urbit/urbit#5470 onto current vere. See that for additional details/history. This is a mostly straightforward, copy-paste port of the changes from that original PR, with the following exceptions: - Boot sequence construction now happens in _pier_boot_make. - We don't modify the way the default boot sequence is acquired (yet). We will want to follow up on the latter, eventually. The %autoprop "prop builder" that was included in #5470 should still operate fine and be useful for automating keeping certain kinds of props up to date. (Save for minimal kelvin compatability disrepair it has fallen into due to the flow of time.)
Adds support for `--prop-file`, `--prop-url` and `--prop-name`, which let one augment the boot sequence of a ship with additional events. Back-ports the vere changes from urbit/urbit#5470 onto current vere. See that for additional details/history. This is a mostly straightforward, copy-paste port of the changes from that original PR, with the following exceptions: - Boot sequence construction now happens in `_pier_boot_make`. - We don't modify the way the default boot sequence is acquired (yet). We will want to follow up on the latter, eventually. I've left `TODO`s in the relevant places. Figured it might be better to be less disruptive to release processes initially. cc @pkova The %autoprop "prop builder" that was included in urbit/urbit#5470 should still operate fine and be useful for automatically keeping certain kinds of props up to date. (Save for minimal kelvin compatibility disrepair it has fallen into due to the flow of time.)
Technically more like, "add your own boot sequence events".
This implements a set of boot arguments starting with
--prop-, used for loading in "props", jamfiles that contain additional events for inclusion in the boot sequence. (The dream is to make this just be a single--propor w/e that auto-distinguishes between filepaths, urls and names, but we're grounded in reality for now.)Intended use cases here include specifying desks to install during boot, bootstrapping Azimuth state, custom userspace configuration, etc. Being able to do these separate from the pill brings some much-needed flexibility and lets us eradicate "multi-pills" from existence.
Main thing to look at is the definition of
$propin base-dev's/lib/pilland the way those nouns get handled inmars.c.Based on and targeting
jb/wip-urthfor @joemfb's convenience.Includes #5428 because we want long opts for this.
Includes #5389 because that should be updated to make use of the affordances this provides.
Draft mode until/app/autopillimprovements make their way in, but the vere part here should be ready for its first review.