This is mostly a preparatory commit to later be able to read the
deviceinfo from multiple places. It has a bit better encapsulation,
and makes the functions methods, so that they can update deviceinfo
file in-place.
This greatly reduces the chance accidentally adding dependencies to the
other (currently unused) variables later on. Getting away from depending
on deviceinfo has a lot of benefits, but mainly it helps offload
device-specific boot configuration to boot-deploy. Handling those
complexities in a shell script is often nicer.
Also, reducing the need to handle variables that contain lists means
that this app doesn't have to worry about how to merge/handle multiple
versions of those. That might be useful later if mkinitfs has to read
deviceinfo config from multiple deviceinfo files.
For example, trying to figure out how to merge these two things is...
ehhh...
a_modules_initfs="abc bar banana bazz"
b_modules_initfs="foo bar bazz bar2 guava"
This is a janky way to capitalize the first letter of the word.
strings.Title was kind of overkill anyways I guess, since the reason for
its deprecation wasn't even anything we'd hit in our usage of it (unable
to detect some unicode punctuation for word boundaries... which a
deviceinfo field wouldn't have anyways...)
fixes#12
U-boot files may be used to generate boot images during boot-deploy stage,
for example u-boot's FIT images, android boot images. If there's no u-boot
directory for device, skip copying.
deviceinfo: add UbootBoardname
Alpine u-boot package places board files in separate directories,
/usr/share/u-boot/$boardname. This param specifies device u-boot subdirectory.
An earlier revision of this patch had test for invalid lines, but I
decided to remove it because deviceinfo is sourced by so many things in
pmOS that it should be /very/ obvious that there are invalid lines or
other garbage in the file.
I also tried to make the parser fairly forgiving if it does encounter
things that don't meet the deviceinfo "spec", so that mkinitfs will try
as hard as it can to make an initfs.
It has been determined that this test isn't really necessary. busybox
gzip is probably not going to break (and would be discovered elsewhere
too if it does...)
fixes#4
A custom extract test includes reading AND writing the extracted archive
contents to /tmp (which is probably a slow disk), so this uses busybox's
gzip -t ("test file integrity") and seems to take about half the time
(~10s vs ~6s measured loosely on pinephone)
The free space check, checksumming, and moving to the final location
will be outsourced to "boot-deploy", so the verification done here is
just to extract the archive to make sure it is valid.
This adds several steps to the "write" action, by writing it to a temp
location, extracting it, checksumming it, copying to destination,
verifying checksum, and using Rename to atomically replace any existing
file in the destination.
This uses sha256 which, after benchmarking, doesn't seem to be any
faster or slower than sha1. md5 was surprisingly slower (on aarch64),
maybe because there are some CPU accelerated things in sha* ?
