[Aboriginal] Splitting up system-image.sh?

[Rob Landley]

(Now that we've got a mailing list back, I'm trying to post to the list
instead of blogging about aboriginal linux design topics.  That way if
you want to respond to any of it, you can easily do so here. :)

I've spent years slowly making the design of this project suck less, via
an incremental series of decisions that generally run like
"mini-native.sh is a stupid name, I should call it root-filesystem.sh.
Having environment variables control what gets built in the root
filesystem is stupid, I should split it into two scripts.  Having a
cross compiler and a native compiler build essentially the same packages
with two different scripts is stupid, I should factor out the common
code such as package builds and make both scripts call them..."

After all that I'm still unhappy with some design decisions, because
I've never been able to come up with a good solution to them.  The "such
and such is ugly/stupid/clearly non-optial" part is easy, but the "I
should do... what?" part.  That's hard.

The system-image.sh kernel build is one of them.  In theory this should
just be another repackaging script like root-filesystem.sh, splicing
together the output of previous stages.  In practice,
SYSIMAGE_TYPE=initramfs needs a just built kernel source directory in
order to bundle a cpio file into the kernel.

Over the years I've put dependency checking into it, with the ability to
detect that the kernel was already there and we didn't need to rebuild
it... and after I stubbed my toe on it breaking a few times I ripped it
back out again as unnecessary complexity that just made the sucker
brittle and hard to maintain and gave me extra configuration stuff to
look up when I wanted to run a test.

  http://landley.net/hg/aboriginal/rev/1163

(Speaking of which: if I can't remember off the top of my head how to
trigger a control, and I wrote it, something is wrong.  Speaking of
which, if anybody has a better suggestion for the name of
$CROSS_HOST_ARCH I'm all ears...)

I'm bumping into this right now because I'm making setup-chroot into its
own script in sources/root-filesystem/sbin and I'm building new system
images to tweak it every time I fix another typo.  (Not testing it on my
host, no.  I had to reinstall my laptop after the first time I ran "make
uninstall" on under buildroot circa 2004 and it suffered host/target
confusion as root while deleting files.  Not going there again.)

The hw- targets are vaguely related to this.  Right now, system-image.sh
isn't quite generic enough.  The kernel build and the root filesystem
image build being tied together like that is ugly and inflexible, and
the _reason_ for it is initramfs.

Back around 2006 I spent a couple weeks trying to figure out how to
replace a symbol out of an ELF file.  You'd think objcopy or something
would be able to do it.  Then I could have the kernel build script
create an ELF vmlinux image, have system-image.sh make a cpio.gz file
(which it basically does internally already) and then splice them together.

Hmmm...  Maybe I can reverse the order.  If I split system-image.sh into:

  1) filesystem-image.sh
  2) kernel.sh
  3) system-image.sh

Then if filesystem-image.sh produces a cpio output file, kernel.sh can
incorporate that when it builds.  (I'd have to copy usr/gen_init_cpio.c
out of the linux kernel source into sources/toys, but I think I'm ok
with that.  I've already got gen_initramfs_list.sh in there and that's
similarly sourced.  Yay GPLv2.)

Thoughts?

Rob