On 27/12/15 19:10, Martin Lucina wrote:
I had several out-of-band conversations with people about config formats
over the last month or so, including people who manage upwards of 10^5
systems whose opinion I trust. The alternatives discussed were JSON, YAML,
XML, or "custom UNIX shell-script/Cisco/other style". Given the goals of:
1. human editability
2. widest possible software interoperability
3. standard, extensible format which will last us for years
4. straightforward and lightweight to parse in C with few dependencies
Goals 2 and 3 rule out anything in the "custom" department. Goal 4 rules
out (most of) XML.
Ruling out XML entirely because most of it is unnecessary is hardly a
reason. XML has been used successfully for runtime information in an
embedded/microcontroller OS running on tens of kilobytes of memory, so
it's definitely lightweight enough for our config use. Concluding that
we can't use XML because some implementations are bloatware is like
deciding to not use kitchen knives because people who don't know which
end is the handle will run into messy problems.
"Many people hate xml with a passion" would have been a better rationale ;)
Now, you've replaced the working json parser which was running below libc
with another json parser which is running on top of libc. What was the
motivation for replacing one json parser with another? No matter what the
answer, the result is not acceptable, since it effectively makes it
impossible to support kernelonly-mode config with the same parser.
Jsmn is not a good enough json parser to write a config parser which can
handle arbitrarily json structures easily. In fact, it (jsmn) is
technically only a tokeniser, so in order to handle unknown-but-valid data
in a robust fashion I'd have had to hand-code a bunch of state machines for
each particular data structure.
I tried this for several days, and the resulting code was both hard to adapt
to changes in the JSON structure and totally unmaintaintable.
Can you illustrate by giving a few examples of the problem? (e.g. by
pointing to the relevant part of the diff)
Generally speaking, the bits of the config which make sense for kernonly
(e.g. network address configuration) should be written on top of
bmk/rumpkernel where at all feasible, not libc. That rewrite is on one hand
a separate change, but on the other hand it must not be torpedoed as part of
a config format revamp.
Fair point, however I was not aware of what your plans were with kernonly
mode as it is still documented as "experimental", much less that
"supporting kernonly" was a requirement for config.c.
IIRC you yourself said earlier this year that you'd like to run ocaml
programs without libc. I don't admittedly know what sort of ocaml
programs you'd want to run, but I'm guessing at least some of them might
want e.g. a network setup, making me think that some sort of -k config
support would derive already from your own goals.
Anyway, the requirement is to not support -k with the config revamp
("separate change"), the requirement is to not introduce changes which
clearly take -k config in the wrong direction ("must not be torpedoed").
