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.
