[klibc] refactoring do-mounts out of kinit

[Mike Waychison]

So, today, I'm using kinit from our initramfs to handle early boot up
sequence.   Our init is actually a shell script that does a some setup
stuff (plugging values into appropriate proc files mostly), and the
script currently passes on to kinit by finishing with "exec /kinit
"$@"".

I have a situation now though, where due to some ubuntu weirdness, I
seem to need to do stuff between the mounting of the root filesystem,
and pivoting into it.   Things I think need to happen include mounting
a tmpfs on to next root's /dev, mounting /proc, and mounting /sys.
Usually, this happens within the initrd built by the distro, but I'd
like to avoid having a separate initrd (as it is much easier for us to
build an initramfs as part of the kernel compile that *just works* for
all the boot environments we care about).

For the moment, it *seems* that the requirement is to just add a bunch
of mountpoints, but I'm tempted to "fix" my problem by refactoring
some of kinit.

Currently, kinit is already setup as not much more than a wrapper that
ties together the following components of the early boot up sequence:

 - ipconfig
 - nfsmount
 - resume
 - run-init

The filesystem detection bits are also available as 'fstype'.

The only thing needed to be split out in the build that would enable
me to replace kinit with shell scripting calls to the components it is
comprised of (allowing me to write setup stuff between the steps of
the boot) is the actual step that does the handling of root=.

I've taken a couple stabs locally of refactoring do-mounts out into a
sub directory at usr/kinit/do-mounts, but that doesn't play very well
with KBuild, as it needs to depend on portions of ipconfig and
nfsmount, which are in sibling directories (and this confuses KBuild
when doing parallel builds).

The alternative I think is to refactor it a bit so that do-mounts code
stays where it is, but a new binary target is created next to the
kinit binary.

Questions:

- Does my approach make sense?
- Anyone have any reasons I shouldn't go ahead with this refactor?