I am at the stage with frankenlibc that I need to set up configuration.
The big problem with configuration seems to be that the different
implementations have very different access to configuration
information. Xen has xenstore, which is a generic key-value store,
userspace has some arrangement of files and block devices, while bare
metal does not have much at all, although some platforms might have
some persistent flash.
The mechanisms that have been suggested before include:
1. Autoconfigure everything. ie dhcp on ipv4, radv on ipv6 (the kernel
implementation may well be sufficient, although it cannot eg set dns
servers, would need a "userspace" client). Automount block devices. At
a minimum you need a way to set mac address even so, in order to get
repeatable addresses though - userspace is ok as you can set these
pre-boot, and Xen can set in config files, bare metal probably has a
physical address stored in flash or similar.
2. Static config. This is mostly a matter of defining a standard
config format and utilities to read it, and having a file system (see
3). It might be even easier if xenstore was a virtual file system that
could be mounted, or plugged into ETFS.
3. Adding a file system to the image. I was looking that this before,
with my lightweight libuntar (25k) to untar an in memory image to the
root file system. The nice way to do this is to allow the user to
append the archive to the binary, then use the elf size to find the
offset, so you don't need to patch the file. This has the advantage of
working anywhere, and can also be used for data not just
configuration.
4. Patching variables in the file, eg to customise a mac address. Less
nice than 3, but for small bits of config might be useful, eg if you
want to customise service discovery parameters. Supporting multiple
images with 3 might be even nicer.
5. Other mechanisms?
Then there is the issue of a standard setup routine, what that should
be called and whether or how the application developer can change the
config. For example there could be an autoconfig routine, and a user
hook, or the user could override the whole config if eg it was a weak
symbol. We clearly want to not have to modify existing programs to do
config.
I am currently leaning towards mainly supporting 1 (will tidy up the
ipv6 autoconf I did for my presentation and work out why it didnt work
in the right place), and then 3.
