set_rcvar() function use?

Mateusz Piotrowski 0mp at FreeBSD.org
Fri Jul 3 07:53:19 UTC 2020


Hi,

On 7/2/20 8:54 PM, Hiroki Sato wrote:
> Pavel Timofeev <timp87 at gmail.com> wrote
>   in <CAAoTqfss_-=N4EGd=XKDA+tzqvK5YZ7Ci6QJZvvip2xc64fYrw at mail.gmail.com>:
>
> ti> Hello, dear community. I'm confused, please, help me.
> ti>
> ti> There is a rc.subr function which was buried[1] and resurrected[2] after a
> ti> couple of years in almost the same form.
> ti>
> ti> I don't know what happened behind the scenes, but I have a question.
> ti> Is it a preferable way to define a rc.conf variable these days in rc
> ti> scripts (again/over and over)?
>
>  I resurrected it because I wanted to change the standard style to use
>  set_rcvar() to declare the user-configurable variables, their default
>  values, and descriptions without losing backward compatibility.
>  There is no clear consensus on this migration, however.
>
>  The primary motivation was to add multi-instance support in rc
>  scrupts[1].  To support this, the set_rcvar() style was required.
>
>  [1] https://lists.freebsd.org/pipermail/freebsd-current/2014-October/052706.html
>
>  Another issue I am aware of is that rc scripts installed by ports/pkg
>  that they cannot have related entries in /etc/defaults/rc.conf for
>  the default values.  So a lot of ports tend to end up with
>  assignments in the rc scripts like this:
>
>  : ${foo_enable=YES}
>
>  This introduces inconsistency and it is difficult to find
>  documentation about which knobs are available.  The set_rcvar() style
>  should mitigate this and also implements a support to obsolete a
>  variable when needed.  set_rcvar_obsolete() will convert the old
>  value to the new variable automatically or emit an error if there is
>  no compatibility between the old and the new.
>
>  I committed set_rcvar() part only in [1], not whole of the
>  multi-instance support.  This is because it was quite difficult to
>  control which version of rc.subr is installed.  If rc scipts in ports
>  use set_rcvar() on older versions of FreeBSD which do not support it,
>  the port breaks.  At this moment all of the supported FreeBSD
>  versions have the resurrected set_rcvar(), so I think it is now safe
>  to use it globally.  Probably we might want to add a version number
>  or feature flags in rc.subr to prevent this kind of situation.
>
>  I am planning to revisit the multi-instance support shortly because I
>  am using it for a long time and I think it is useful.  While I did
>  not receive a strong objection to it so far, it is also true that
>  adopting the set_rcvar() style was not discussed properly.  I would
>  like more feedback before moving forward.

AFAIR, manu@ was concerned at some point that using set_rcvar() extensively
might result in slowdowns on embedded systems.

Regards,
Mateusz



More information about the freebsd-ports mailing list