From owner-freebsd-rc@FreeBSD.ORG Mon Mar 31 03:18:47 2014 Return-Path: Delivered-To: rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 529C966D; Mon, 31 Mar 2014 03:18:47 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD451D85; Mon, 31 Mar 2014 03:18:46 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.8/8.14.8) with ESMTP id s2V3INK9027287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 31 Mar 2014 12:18:33 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.7) with ESMTP id s2V3IKJZ026283; Mon, 31 Mar 2014 12:18:22 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 31 Mar 2014 12:17:57 +0900 (JST) Message-Id: <20140331.121757.1100840815853109946.hrs@allbsd.org> To: dteske@FreeBSD.org Subject: Re: network.subr _aliasN handling From: Hiroki Sato In-Reply-To: <04f701cf4c85$d1929680$74b7c380$@FreeBSD.org> References: <04c901cf4c5d$a6a4a030$f3ede090$@FreeBSD.org> <0EBE3981-DC85-414D-85B8-7638F172040A@dataix.net> <04f701cf4c85$d1929680$74b7c380$@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Mar_31_12_17_57_2014_569)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Mon, 31 Mar 2014 12:18:35 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, LOTS_OF_MONEY,RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: jhellenthal@dataix.net, rc@FreeBSD.org X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 03:18:47 -0000 ----Security_Multipart(Mon_Mar_31_12_17_57_2014_569)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit wrote in <04f701cf4c85$d1929680$74b7c380$@FreeBSD.org>: dt> But that wouldn't have deterred me. 30+ days of dt> silence is equivalent to acceptance -- just that I dt> had noticed that the patch could be expanded to dt> include mdconfig{,2} scripts. Was going to wait a dt> full day to see if anyone balked at the expansion dt> to include mdconfig{,2} and then move forward. I like the direction in general, but there are two more comments: 1. sort(1) cannot be used in rc.d/mdconfig and should not be used in rc.d/netif because it is before rc.d/mountcritremote. It is one of the reasons why a loop is used for fooN variables instead of symbol table lookup. This may be a controversial point because our installer is now using a single partition for whole of the base system. However, rc.d/ scripts have been implemented in consideration of / and /usr separation and it gives configuration flexibility. I personally think we should avoid grep, sort, etc. in scripts before mountcritremote whenever possible, and must be used in ones before mountcritlocal. And another question: is the order important in practice? I am wondering if dropping sort(1) is harmful except that the behavior is not intuitive. 2. Please put the normalization part into a function and use it in get_if_var(), too. Adding another code for the same functionality makes maintenance difficult. It degrades the performance a bit but I think maintainability is more important for that. -- Hiroki ----Security_Multipart(Mon_Mar_31_12_17_57_2014_569)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlM43mUACgkQTyzT2CeTzy1SIACg1G7iUXv9JxwrOwwqfiVCo0Fj czoAn0OmcdAu+/CW95SiB3/5pboxut+p =Gokm -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Mar_31_12_17_57_2014_569)----