CDINIT version 0.8.0

CDINIT is used for initializing a CD booted system to load up tmpfs
file space with files from a tar file on the CDROM and subsequently
run the real (now loaded) init program.  All of this happens in
process ID number 1.

On Intel-based PC systems, CDROM booting is generally done using the
El Torito format.  The principle feature of the El Torito format
used by nearly all PCs that can boot a CDROM is floppy emulation.
While El Torito also supports non-floppy emulation, this is not yet
universally supported by all PC BIOS implementations.  To make a
widely bootable CDROM, the El Torito floppy emulation must be used.

The maximum size of floppy emulation El Torito supports is 2.88 Mbytes.
While this is enough to load a kernel and a minimal initial ramdisk,
it is not enough for a more sophisticated system.  Typically up to
4 Mbytes to 5 Mbytes could be compressed into the 2.88 Mbyte image,
but this also includes the kernel, leaving less for the initrd.  With
RAM capacities on today's PCs being 64 Mbytes and larger, much more
can be done from a CDROM booted system if there is a convenient way
to load more into RAM.  While this can be done in many ways, CDINIT
provides a convenience by doing the loading before init even starts.

Another problem that exists is that the initial ramdisk is ramdisk
and has a size limitation.  The standard default is 4 Mbytes.  This
does limit what can be loaded, requiring more space be set up.  CDINIT
uses tmpfs to get more space in a way that resides in RAM but can be
swapped out if swap space is made available.

CDINIT is designed to be used with the BICK (Bootable ISO Construction
Kit) package, but could be used separately.  It is being designed to
handle both Intel and Sparc architectures by having different versions
compiled with specific name strings integrated differently to make the
different version look for the appropriate files on CD.  This is used
to create a dual-platform bootable CDROM.

Feedback

Since this is an alpha release, I expect things to be broken.  Feedback
on problems you find is what an alpha release is all about.  Things like
"It doesn't work on my machine" are kinda useless without having your
machine, though.  Alpha releases are for people who expect to be able
to dig into the problem themselves and figure out what's wrong, if not
actually figure out what to fix.  Feedback like "it does not work" does
not do me any good (I already know it doesn't work).  Feedback like
"I got this error message ..." is at least somewhat helpful.  If you can
pin down what I did wrong, that would be most helpful.

You can send feedback to me at this email address:  bick@ipal-dot-org