When using component-based design and development, the various components
composing a system/applications can be executed inside Virtual Machines (VMs).
For example, using QEMU/KVM.

In the experiment shown in the lab, the VM is started with something like
	qemu-system-x86_64 -initrd periodic_test.gz -kernel bzImage -machine pc,accel=kvm ...
where "bzImage" is a compiled Linux kernel image, and "periodic_test.gz" is
an initramfs containing the minimum amount of files needed to boot and a
test application ("periodic_thread") - in a real system, the test application
will be replaced by a real component.
This technique can be useful to easily and quickly deploy components without
having to distribute full disk images (the initramfs image is few MB large,
while a full disk image is more than 100MB - it can be various GB in many
situations).


An initramfs is a pseudo-filesystem decompressed in RAM at boot time: it
has no filesystem metadata, and is something similar to a compressed archive
that is loaded by the bootloader (GRUB, or the QEMU's bootloader) and
expanded by the kernel. The compression format is gzip's one (gz) and the
archive is stored in the "newc" variant of the "cpio" format.

At boot time, the kernel unpacks the basic initramfs into a RAM-based disk
(similar to a "tmpfs") by treating it as compressed (gzipped) cpio archive.
Then, it mounts such a RAM-based disk and uses it as the initial root
filesystem.

The original initramfs purpose was to provide some way for the kernel to
load device drivers before the real disk is mounted (the disk might be
accessed through device drivers that are in kernel modules... So, where
can these modules be loaded from?). However, many embedded systems use
an initramfs as their real root filesystem.

The big advantage of using a gzipped cpio archive is that these formats
("gz" and "newc") can be concatenated, so an initramfs can be generated
by independently generating a minimal initramfs "core" an the filesystem
containing the component. The two filesystems can then be concatenated
using the "cat" command.


The "core" initramfs (minimal initramfs containing only the files needed
to boot the system) is based on busybox (https://busybox.net/) and some
custom scripts (/etc/init.d/rcS). It can be generated by using the
"BuildCore" package distributed on the course website.
To do this, create an empty directory and run "buildcore.sh" inside it.
For example:
	mkdir Tmp
	cd    Tmp
	sh ../BuildCore/buildcore.sh $(pwd)/minimal_initramfs.gz
Notice that "buildcore.sh" accepts ad a parameter the _absolute_ path of
the desired output file and the "$(pwd)" prefix is needed to obtain such
an absolute path ("pwd" returns the absolute path of the current directory). 
The minimal initramfs is now in the "Tmp" directory (thanks to "$(pwd)")
and can be used as an argument of the "-initrd .." parameter in the QEMU 
command line. Of course, it is not too useful, because the filesystem image
does not contain any component or test program.
The component can be added by creating its filesystem image (in an emtpy
directory):
	mkdir ComponentImage
	cd    ComponentImage
	mkdir Component
	cp ../PeriodicTask/periodic_thread Component
then, the content of the fs can be stored in an initramfs image by using
the following black magic:
	find . | cpio -H newc -o | gzip > ../component.gz
and finally the two initramfs can be concatenated:
	cd ..
	cat Tmp/minimal_initramfs.gz component.gz > test_initramfs.gz

Notice that the PeriodicTest Makefile contains a target rule for
generaring something similar to the "component.gz" initramfs described
above (it is named "test.gz" and can be generated with "make test.gz").