[talk] classifying BSD init

Sujit K M sjt.kar at gmail.com
Mon Aug 31 10:18:23 EDT 2015


On Mon, Aug 31, 2015 at 12:32 AM, Patrik Lundin
<patrik.lundin.swe at gmail.com> wrote:
> I generally like the idea of a "one module per project" approach,
> there are pros and cons in both directions though.

Just out of curiosity, what is the difference between one module per project and
the present scheme. IMHO there is a lot difference in *BSD as Project. Though
This might be true in the case Linux Distros. You have X11 Dbus it is
functioning
the same way in Linux Distros, But not in the case of BSD.

>
> 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.

This is plainly depends on the refactoring you do.

>
> 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.

This is purely refactoring.

>
> 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... :).

I agree with this.

>
> --
> Patrik Lundin



More information about the talk mailing list