Finit modules and static linking

[vazub]

While playing with Finit and adjusting it for use in my custom distro, I stumbled upon an issue #394 , hence triggering this discussion, with 2 distinct themes:

1. For some reason, my default expectation (I could be wrong of course) was that any functionality that is compulsory in the product, should not be organized as a runtime module, in order to avoid introducing any potential requirements for dynamic loading. Apparently, this does not seem to be the case for a bootmisc module, which although not considered optional anymore, is still being built as a module and treated as such. I am rather curious about the rationale for such a design and whether the author would consider refactoring that at some point.

2. This also leads to a bigger philosophical discussion, as to whether dynamic linking is a reasonable approach in general, for such a fundamental component as init, as it increases the potential bug surface and needlessly complicates further distro/libc update and maintenance. While one can argue that some init systems, cough SystemD cough do link dynamically, they inherently depend on dynamic Glibc functionality, like NSS, and overall exhibit a kitchen-sink approach, much criticized elsewhere, as you are probably aware of.

[troglobit]

The plugin system was added over 10 years ago to Finit. At the time a lot of the development was driven by requirements from a previous $DAYJOB and we needed ways to squeeze in functionality on targets with very little RAM/flash. The company had several plugins that other functionality in the system required. Over time open plugins were added upstream (by me and others) to rework the base ideas and get more generic implementations, many of these open plugins were modeled on their SysV init script counterparts, like bootmisc.

Some plugins were deemed critical to provide base functionality in a generic Linux system, like bootmisc but also pidfile (which is required for <pid/condition> to work), and although they live in the plugins directory they were always built. (For static builds they are always included in libplug.a and linked to finit in the final build step.)

For all of this to work, of course, it is expected that users follow the build & install directions. But yes, there have been many bug reports over the years where people ignore the make install-strip part and just grab the resulting finit binary, in some expectation of what would happen. There are not just core plugins that would be lost this way, Finit has a few other helper programs too, e.g., logit, getty, runparts that are installed in /libexec/finit (default path), which would also constitute as load bearing.

The key idea here though is that a plugin can be overridden by the user. At my previous $DAYJOB we make install:ed Finit and then make install:ed a set of local plugins that replaced some of the native ones (netlink and bootmisc among them), and others that extended the system in other ways, e.g., custom conditions or legacy behavior.

So, just because something's not optional using the configure script, doesn't mean it necessarily should be moved to src/.

While on the topic of bootmisc, which sets the system up in a Linux FHS type of way, I've had quite a few complaints over the years that it's hard to use finit with non-FHS compliant systems. Making it harder to opt-out of what bootmisc provides would make it even harder for those users. In theory, at least, it would be possible to start a system entirely without bootmisc. It would be limited and had to use a lot of tricks, but it's not impossible. I've set it as non-optional in configure though just to provide some sane defaults.

I hope this answers your questions.

As a side note, and to be 100% clear, not addressing you specifically but giving bit of a background on me. The project is not new, it is built on top of lots of old sediments of requirements and user input over a long period of time. Sure, requirements change and Finit evolves, but for every major proposed change, there will always be users for which their use-cases would break. As a maintainer it is incredibly difficult to navigate -- you know the story of how the project ended up where it is, and you know where you want take it next, but you have to argue and explain to end-users that have their own view of how things should be, some even expect you to work for free to fix their use-cases, implement and maintain their features, and support them. As I've gotten older (and wiser?), I've stopped doing the latter part since it came to completely consume my life and took a lot of the fun out of working on my previously favorite hobby projects. Today I try to instead focus on what I need and want myself, find the fun again, help review and curate contributions from active users/devs, and direct users with other needs to the Fork button.

[vazub]

Thanks for the detailed insight! And no worries, I fully respect the "scratch my own itch" approach, as I am embracing that myself with own distro as well. In this case with Finit, it also means I would probably have to come up with some creative workaround myself. Oh well, such is "the Way" of opensource, I am fine with it :)