Re: Oversight in /etc/defaults/rc.conf

On Tue, Jul 12, 2016 at 03:10:43PM +0100, Matthew Seaman wrote:
> On 07/12/16 13:27, Glen Barber wrote:
> > On Tue, Jul 12, 2016 at 07:17:19AM +0100, Matthew Seaman wrote:
> >> I just upgraded my main machine to 11-STABLE.  Things are mostly working
> >> fine -- however I did notice that the new iovctl rc script is apparently
> >> enabled by default.  That seems like a trivial omission:
> >>
> >> Index: etc/defaults/rc.conf
> >> ===================================================================
> >> --- etc/defaults/rc.conf	(revision 302482)
> >> +++ etc/defaults/rc.conf	(working copy)
> >> _at__at_ -695,6 +695,7 _at__at_
> >>  rctl_enable="YES"		# Load rctl(8) rules on boot
> >>  rctl_rules="/etc/rctl.conf"	# rctl(8) ruleset. See rctl.conf(5).
> >>
> >> +iovctl_enable="NO"
> >>  iovctl_files=""		# Config files for iovctl(8)
> >>
> >>  ##############################################################
> >>
> > 
> > I'm not sure I understand.  Is there a functional and/or performance
> > impact with it enabled by default?  (Note, I don't disable it in my
> > rc.conf, and there is no /dev/iov/* on my system.)
> 
> I'm not religious about it being turned off per se.  More that it should
> have a clearly defined on/off state shown in the defaults.
> 

Ah, this was my confusion.  Thank you for clarifying.

> I went for 'off' following the general principle that rc.conf items
> should mostly be off by default and require specific action to enable.
> Yes, there are exceptions to this rule, but I see no particular reason
> that iovctl should be one.  What's the advantage to turning it on by
> default on every FreeBSD installation?
> 
> However, even if it's felt it should be enabled everywhere, then
> shouldn't /etc/defaults/rc.conf have:
> 
> iovctl_enable="YES"
> 
> instead?
> 

I'm not pro -vs- con either way.  But I think this should be resolved in
head first, and MFC'd to stable/11, as this isn't something I think
should be in the "checklist" when branching.  I think you are really
pointing out a different "bug" here.

Glen