New .svc config file format

[troglobit]

The oneliner format for configuring services is getting a bit crowded, and at times very wide.

What follows is an unfinished proposal for a new service definition that could fit into Finit w/o much refactor:

service zebra:quagga {
    runlevel = 2345
    exec = zebra -A 127.0.0.01
    desc = "Zebra routing daemon"
}

service ospf:quagga {
    runlevel = 2345
    cond = pid/zebra:quagga
    exec = ospfd -A 127.0.0.01
    desc = "OSPF routing daemon"
}

[jorgensigvardsson]

I like it! One liners are terse and compact, quick to read, but this is easier to read.

Are you thinking about supporting both formats for some period, or perhaps provide a conversion tool? I can always help if you need it. I've been a parser nerd ever since I took that compiler construction course.

[troglobit]

Yeah, we started out simple, which was a good get-shit-done approach. But we desperately need a new format, and a new extension instead of .conf. People confuse the service declaration file with the daemon-specific .conf file. I've been toying around with the .svc extension in several places (FAT is still an issue, hence the old DOS .ext).

Definitely to support both formats, for a very long transition period, but only support new features in new format.

Grafting this onto Finit will be a monumental task, so any help is definitely appreciated! <3

[jorgensigvardsson]

Haven't had a look at the parser yet but is there some kind of backend the parser calls into? If not, then maybe a refactoring of the parser could be a good starting point. Are there any tests for it?

I like the new format very much. It's much nicer for diffs/conflict resolution.

I might be "gräsänkling" for a couple of days in 2-3 weeks, so I could probably get things done.

I presume you want a small foot print, so no dependencies on big runtimes. The grammar and tokens look very simple, so I'm guessing a handwritten lexer and RD parser would do the job nicely without adding huge complexities. What's your opinion of using mmap on finit targets? I find mmaping files much more straightforward than heavy handed I/O. The kernel is very efficient at handling loading pages in sequential access. :)

[troglobit]

The idea was to use libConfuse, or another homegrown parser, fit for purpose. An alternative was to adapt the yacc+lex .conf parsers used in mrouted, pimd-dense and pim6sd. You are correct in your assumptions, we still want to keep things light and as few deps as possible, it is delicate work and we cannot even rely on the ability to load .so files -- static finit is one important use-case to cover. So this needs careful planning unfortunately.

Please note, this is a feature planned for future (5.x), I do not plan to add this any sooner than that. There are enough minor bugs and features to sort out first in the 4.x series that are more important than this. Sorry

[jorgensigvardsson]

Got any low hanging fruits to get up to speed with? Seems like I have to learn finit at some point anyway! 😅

[troglobit]

Sure, I may have something in mind for you @jorgensigvardsson :smiley:

First though I'd recommend getting a NetBox + custom Finit set up, using the Buildroot OVERRIDE mechanism.

I usually have two build directories, output-zero/ and output-basis/ that I test against with Qemu (make run). That way I get to test both 64-bit and 32-bit targets with very little effort. I have the following file symlinked from my NetBox clone into each of the output directories:

# ~/src/netbox/local.mk
FINIT_OVERRIDE_SRCDIR = /home/jocke/src/finit

I then have two different terminals where I set O=~/src/netbox/output-zero and O=~/src/netbox/output-basis, respectively. Every time I change something in Finit, I do the following from each terminal to rebuild and test:

$ make finit-rebuild all
$ make run

When you have that set up, and have verified you can modify something simple, I can ping you from another issue that I think you might like! Brace yourself, I'm going to be real tough on you :smirk:

[jorgensigvardsson]

Ok!

Now it's time for me to come up with something clever. I have burned myself too many times in the past with builds and other processes being dependent on "loose" variables. I wonder if I can tweak gnome terminal to do my bidding...

[troglobit]

Personally I prefer Terminator, can be split horiz/vert infinitely, so I can have multiple "views" into the same build/target. And then I use different tabs for other targets. Tobias have a PS1 that gives a slightly different prompt depending on the O variable, that's clever and something I should do myself.

[jorgensigvardsson]

Well of course! PS1!! I was hell bent on changing the title of the terminal window, but heck, how often do I look there? Tobbe is a clever guy. :)

[hongkongkiwi]

I wanted to bring up again the idea of having a simple \ which allows config lines to be broken up which would allow more readable configs in the existing config format.

From what I can see, there's no reason for a slash to ever be in a config line and probably it should be parsed out of the command that's run as it could get weird, so why not use it to break up our long long config files?

It would really help me a lot to have all the configs a bit more readable.

[troglobit]

@hongkongkiwi OK, let's reopen #186 instead and keep this one about the new .svc config format.

[troglobit]

Continuation character support added in 9046b6f to current .conf file parser by using fparseln().