we then "import" them straight back into base.nix - it's not
as though you can opt out of having a kernel. But this means
they'll appear separately in the documentation
This is in preparation for writing something that extracts them
into documentation.
user configurations now call config.system.service.foo.build { ...params }
instead of config.system.service.foo
the parameter type definitions themselves now move into the
config stanza of the module referencing the service
new helper function liminix.callService
The only service moved so far is dnsmasq
We use (abuse, arguably) the nixos module system for typechecking. Un
the plus side, it gives us documentation of the options and their
expected types. On the downside, the error message doesn't tell us
the file in which the error was encountered.
(This is subject to change, if I can find a better way)
The objective here is that services which depend on global config
(e.g. kernel config or busybox options or static paths in the
filesystem) now live under config.system.service, and are added
to that collection by the module that defines the necessary state.
This is a first step: the services will be configured by a typechecked
attr set instead of the arbitrary arguments that
pkgs.liminix.networking.pppoe accepts
New rules: everything under "config" that isn't actually configuration
(e.g. build products) will in future live in config.system. This is
the first step.
By using the kernel "nolibc" header to avoid requiring a C library, we
can bring the initramfs size to around 4k
This does involve a tiny bit of inline mips assembly which I'm not
sure about. gcc seems unwilling to generate the code to load $gp at
function entry of main(), so we do it by hand - but I'd rather find
out why gcc doesn't.
systemconfig (a.k.a "activate") is run from the initramfs. Converting
it from a shell script to an executable means it doesn't depend on
there being a shell in the initramfs
