Date: Fri, 3 Jul 2020 09:53:13 +0200 From: Mateusz Piotrowski <0mp@FreeBSD.org> To: Hiroki Sato <hrs@FreeBSD.org>, timp87@gmail.com Cc: freebsd-ports@freebsd.org, manu@FreeBSD.org Subject: Re: set_rcvar() function use? Message-ID: <34921b6e-ce3a-13e4-0cc1-3ca47b5a9cef@FreeBSD.org> In-Reply-To: <20200703.035403.856368268140192104.hrs@FreeBSD.org> References: <CAAoTqfss_-=N4EGd=XKDA%2BtzqvK5YZ7Ci6QJZvvip2xc64fYrw@mail.gmail.com> <20200703.035403.856368268140192104.hrs@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On 7/2/20 8:54 PM, Hiroki Sato wrote: > Pavel Timofeev <timp87@gmail.com> wrote > in <CAAoTqfss_-=N4EGd=XKDA+tzqvK5YZ7Ci6QJZvvip2xc64fYrw@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34921b6e-ce3a-13e4-0cc1-3ca47b5a9cef>