[talk] classifying BSD init

Patrik Lundin patrik.lundin.swe at gmail.com
Sun Aug 30 15:02:19 EDT 2015


Being the one who refactored the service module into the classes
format it has today, as well as being the initial author of OpenBSD
support my thoughts are these:
I generally like the idea of a "one module per project" approach,
there are pros and cons in both directions though.

In a general sense one drawback I see is the potential for code duplication:
* There is currently some code that is shared among FreeBSD and
NetBSD, specifically service_enable_rcconf().
* There is also all of the state calculation, command execution code
etc, which is currently shared among all supported platforms and not
just the BSDs.

Is there a plan to manage this in some way? Maby move these functions
into some central location instead so they can be called by separate
modules? This is a relevant question both for a unified bsdinit
module, as well as having one module per project.

On a more specific OpenBSD note:
Calling the OpenBSD module "rcctl" might be misleading, given that
this only applies to versions of OpenBSD new enough to actually have
that utility (older versions use the /etc/rc.d scripts directly).
Given that the package manager is called "openbsd_pkg", maby calling
it "openbsd_rc" or "openbsd_service" would be better (as well as not
dependant on the "service manager of the day")?
I guess the main drawback of this naming convention would be if
another OS decided to port the OpenBSD rcctl utility, however, this
begs the question if the "rcctl" module would be separate from a
"openbsd_rc.d" utility for the older OpenBSD systems.... ugh... :).

Patrik Lundin

On Sun, Aug 30, 2015 at 7:28 PM, Brian Coca <briancoca+nycbug at gmail.com> wrote:
> Thanks, I did not know this, the service plugin is probably not
> currently working with DragonFly, I'll try to fix that also.
> On Sun, Aug 30, 2015 at 1:13 PM, Justin Sherrill
> <justin at shiningsilence.com> wrote:
>> Fly, which does not end with "BSD".  (And is rcconf)
> ------------
> Brian Coca
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/talk

More information about the talk mailing list