Ikey Doherty
I do have local diffs for moss boot though
Ie the structure of a boot::Environment
It's gonna be absurdly easy to finish this stuff up
clr-boot-manager was harder due to C being resistant to abstractions without relying on function pointers
And not understanding whether the target filesystem was a real install, or an image
And atop that having to map all of the kernels in the directory to entries and sort them
With moss we won't have these issues, we have the Installation object
We also lock to each state, which is already managed.
And no need for us to manage or clean /usr like cbm does
By and large it's a case of populating moss boot with a bunch of kernel configs and let it do its thing
So we walk all states, look through them for kernels, and store a set of these boot environments
Then moss boot basically just dumps them in the right place on disk
Removing anything unneeded after
Piece of piss
The main reason for this cbm stuff is stateless root= boot parameter
Instead of needing the explicitly managed mount points and a global config, the code can figure it out.
So it'll automount and discover esp if not booted, detect lvm vs btrfs etc for / partition
And for brownie points merge boot parameters from so called cmdline files
I really can't stress enough how easy this is now thanks to the design of moss
The mental blocker was always "but we need to hold onto old kernels to make module loading after updating/ path change"
But we already do that with states ... sooo change the argument and teach the tooling to read from old directories
Voila.
(So instead of /usr/lib/modules wed look at /.moss/root/$id/usr/lib/modules)
ermo
How might Solus achieve a similar (if not exactly identical) level of functionality?
Just asking the question so it can rummage around in your brain until such a time when Fabio, Silke and Reilly eventually begin porting it.
Ikey Doherty
Solus relies on so-called ghost paths, aka permanent paths in eopkg parlance
And leaves kernels behind to be cleared from "source" (usr) by cbm
An appropriate cbm replacement could effectively enumerate the usr tree for available kernels and map them into a boot::Environment for the moss boot code to handle
Finally it could then opt to remove the associated auxiliary files and modules for a GC policy
As the moss boot side will clean up anything in the esp namespace not passed in the vector of boot environments
So in reality a fairly minimal wrapper / effort required
While benefiting from easy FS management functions in rust that actually work properly
Such as recursively removing a tree.
In C land we need our own rm_rf nica functions wrapping nftw
Which is just another thing to test
Rather than being stdlib
Context: