From owner-svn-src-head@FreeBSD.ORG Sat Mar 6 19:41:28 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64CEF1065673 for ; Sat, 6 Mar 2010 19:41:28 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id E1D708FC0A for ; Sat, 6 Mar 2010 19:41:27 +0000 (UTC) Received: (qmail 23257 invoked by uid 399); 6 Mar 2010 19:41:27 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 6 Mar 2010 19:41:27 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B92AFE7.4040200@FreeBSD.org> Date: Sat, 06 Mar 2010 11:41:27 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Alexander Leidinger References: <201003051434.o25EYXBR024375@svn.freebsd.org> <20100306162535.000078b8@unknown> In-Reply-To: <20100306162535.000078b8@unknown> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r204759 - in head: etc/defaults etc/rc.d share/man/man5 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2010 19:41:28 -0000 On 3/6/2010 7:25 AM, Alexander Leidinger wrote: > On Fri, 5 Mar 2010 21:18:00 +0000 (UTC) Doug Barton > wrote: > >> On Fri, 5 Mar 2010, Alexander Leidinger wrote: >> >>> Author: netchild >>> Date: Fri Mar 5 14:34:33 2010 >>> New Revision: 204759 >>> URL: http://svn.freebsd.org/changeset/base/204759 >> >> I've got no comments on the jail-related stuff given that my >> knowledge of jails is almost non-existent. However I wish you had run >> your diff past freebsd-rc@ since if you had I (or someone else) could >> have let you know that the attached patch is a much cleaner way of >> implementing the bit about conditionalizing "parallel" execution >> (which, to the extent I understand the problem I agree with your >> solution of only doing it at when starting, FWIW). >> >> In general we try to avoid having any code in rc.d scripts run >> unconditionally. In this case it's harmless (although every cpu cycle >> counts) but in other cases it can cause problems, which is why as a >> general rule it's safer to avoid it altogether. > > I assume your version covers onestart, forcestart faststart and start > (I can imagine situations where a prestart should be different from a > preforcestart, but I doubt we differentiate in the code). The label to start is stripped in rc.subr (and a variable is set to indicate that it was present) before we get to processing start_precmd. > The reason why I chose the case was, that forcestart and onestart are > more interactive options. I could imagine that someone tells in the > future that it may be better to ignore the jail_parallel_start in those > cases. Can the one/force part be detected in the prestart? It could (by testing for the variable) but I would be resistant to the idea of overloading it like that. It's hard enough to get people to understand onestart as it is, I don't want to confuse them by having it do "magic" for one particular service. > The trick with command_args is neat, but it is a pitfall in case > someone wants to use it in the future. Wouldn't it be better to add the > ampersand to it instead of letting the ampersand replace the value? Yes, obviously if someone wants to use command_args for an additional purpose down the road changes will have to be made. It's not in use atm however, so IMO simpler is better. > Whatever your answers are, feel free to change what you want to change > (as long as the feature remains... my main concern is to solve the bugs, > not how to solve them). Okey dokey, thanks. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/