On 21/10/15 15:30, Martin Lucina wrote:
I still care very much about a tool to facilitate quick iteration for
developers (and more). In fact, I think it's absolutely essential for wider
adoption of rumprun by developers or sysadmins who do not necessarily have
systems programming experience.
With "quick" interation:
1) vi open in one terminal. edit + save
2) <up-arrow results in:>rumplaunch -c configs
$some-copypasted-params<enter>
Without "quick" iteration:
1) vi open in one terminal. edit + save
2) <up-arrow results in:>rumpbundle configs; $some-copypasted-params<enter>
So the difference is that phase 2 takes half a second longer, usage
otherwise 100% same.
Not sure why systems programming experience would be a concern there.
However, it is now clear to me (and your "Rise and Fall of the OS" article
helped with that) that any such tool involves introducing policy of some
kind (e.g. "convention over configuration", "autoconfigure everything",
...) and that such policy should be implemented at a higher layer built on
top of (and possibly developed independently from) the rumprun stack, not
as part of it.
It follows from the above is that config.c should be an optional,
swappable, component, but I take it that's not controversial in any way?
Dunno, hadn't thought about a pluggable config.c. Can you give a
concrete example of when replacing the config.c would be necessary?
Autoconfigure everything sound like a particular config, not your own
config.c implementation. Doing some custom, unsupported-by-config
networking configurations sounds either like a multibaked binary and
params for it, or an __attribute__((constructor)). I can't quite think
of a situation where pluggability to config.c would be needed.
My initial reaction is that if people need to start by "la la la writing
my own config module in C", the one we provide sucks too much (see also
the argument you made about non-programmers). Plus, as usual, opening
up the necessary interfaces to the public requires the typical 10-100x
effort in figuring out what they should look like (which is why we keep
having these arduous threads).
On one hand, Lampson writes "don't hide power", and on the other hand he
writes "keep secrets". It's not always obvious where the division goes.
So, like I said, I hadn't thought about optional config modules, and
therefore I'll lean toward the simplicity of "keep secrets".
I don't think it's controversial if someone demonstrates a clear need.
However, what I think we should be shooting for now is people being able
to impose that upper layer config tool *without* having to start
rewriting the lower-layer bits. After all, that's what an OS-like
component should provide.
