Date: Sat, 14 Jan 2012 16:59:37 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Doug Barton <dougb@FreeBSD.org> Cc: Hiroki Sato <hrs@FreeBSD.org>, freebsd-rc@FreeBSD.org Subject: Re: Making use of set_rcvar. Message-ID: <20120114155937.GH1694@garage.freebsd.pl> In-Reply-To: <4F10D130.8080808@FreeBSD.org> References: <20120109.223510.1979757999064039809.hrs@allbsd.org> <4F0FFFF7.4090105@FreeBSD.org> <20120113141058.GE1662@garage.freebsd.pl> <20120114.093209.917724318321412912.hrs@allbsd.org> <4F10D130.8080808@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--ewQ5hdP4CtoTt3oD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jan 13, 2012 at 04:49:52PM -0800, Doug Barton wrote:
> On 01/13/2012 16:32, Hiroki Sato wrote:
> > And I do not think it is a good idea to commit something related to
> > this topic while the discussion is ongoing.
> >=20
> > We have reached a consensus that `set_rcvar` is expensive, but for
> > whether using literal or variable we haven't.
>=20
> Quite frankly I'm not interested in the consensus at this point. You and
> others have brought up several justifications for the way you want to do
> it, and I've systematically pointed out that they're all wrong.
> "Consensus" doesn't mean something is right, it just means it's the
> least objectionable option, which is a terrible way to run a railroad.
>=20
> Chris was right that there is absolutely no question that not having to
> dereference the variable is faster. How much faster really isn't the
> point. Every little bit helps, especially on embedded/slower systems.
So, every little bit helps when it comes to boot time, but every little
bit doesn't help when it comes to reusing existing scripts?
You only think you pointed out the arguments given are wrong. Because
nobody addresses claims like 'it is 31337 to use variables, so don't do
that', doesn't mean they are valid, it means they are not even worth
addressing.
Also, we don't currently use hardcoded names consistently across all
rc.d scripts, so this is not about changing current world order.
Currently we have total mess and two ways of cleaning it up: one being
${name} usage and the other being hardcoded names. All this means it is
not about convincing you that we should move from hardcoded names to
variables, but to find convensus which method we should start using as a
rule and how to clean up what we currently have. Using your logic, I
could as well say that you provided no convincing arguments, so it of
course means we are going with ${name} option. It doesn't work like that.
To sum up.
There is currently only one candidate for a valid argument behind
hardcoded names - speed. To make it a valid argument you need to provide
a prove, because this claim may be indeed proved. Based on the prove we
can either forget about this argument if there is no measurable
difference or decide if the slowdown is acceptable (if there is one).
Are there any other arguments on the table?
For using variable there is an arguments that it will make reusing
existing scripts easier and making the code cleaner. Eliminating every
hardcoded name does help a bit with script modification and makes the
process less prone to human errors, especially because there is no
compiler to tell us something went wrong. I'm also not alone in support
for this argument.
=46rom this summary it is quite clear to me, that if we are going to
continue this discussion, proformance claim has to be proved. Without
the prove this option is left with no valid arguments.
--=20
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl
--ewQ5hdP4CtoTt3oD
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
iEYEARECAAYFAk8RpmgACgkQForvXbEpPzSlhACeOkApJpDy5iakwkZifc0bp1te
pRoAn0vGHPSWHOW7b/BcvtI4FVWMcN8V
=qDXq
-----END PGP SIGNATURE-----
--ewQ5hdP4CtoTt3oD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120114155937.GH1694>