From owner-freebsd-rc@FreeBSD.ORG Sat Jul 6 08:55:15 2013 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 922EFC91; Sat, 6 Jul 2013 08:55:15 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 660D41E3B; Sat, 6 Jul 2013 08:55:15 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id ld11so2843152pab.36 for ; Sat, 06 Jul 2013 01:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=XKEgl20qM9hjCBP6UH7Xj86aPeFi66qFr3kOytT2v+U=; b=PmCpeC/vT0TBIhTzL0HJdruLVl1KyBfOsZx84OGc5BqtnfE2WsK/K2o3hIsIM4yQdE qpQhYc2ScygQJXV5FgpZgwuQ07aa4CNCpchHLtmHSPp+RtQGlgO26qXMVK3Tfpg8B89q MRSYZMebkd4rkgHiV6me4UtcunTjqfXaZ3M5HBcfW+aL6R0Trgqaj5LLh1BugbNTrbC+ 3k5/lWxQOkZt8ZK9fNqeZCCOMAaj3iPn+lCHB9zaUsyA1LRREf6dkbZiZMHVOTwMIFJl Vs8Ffdu4HFcM9wN17cldrqdTDoYf6SGjHn6WZOMgocTkplwVNUXiSzFucN4DNjLGSMYf /tTQ== X-Received: by 10.68.217.137 with SMTP id oy9mr12882729pbc.130.1373100915146; Sat, 06 Jul 2013 01:55:15 -0700 (PDT) Received: from [10.13.64.69] (mobile-166-147-080-076.mycingular.net. [166.147.80.76]) by mx.google.com with ESMTPSA id ib9sm11248901pbc.43.2013.07.06.01.55.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jul 2013 01:55:14 -0700 (PDT) References: <201307060413.r664DmT5009602@svn.freebsd.org> <43915FB0-442B-42CA-BA1A-E346D95838B5@gmail.com> <13CA24D6AB415D428143D44749F57D7201FB2721@ltcfiswmsgmb21> Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: X-Mailer: iPhone Mail (10B329) From: Garrett Cooper Subject: Re: svn commit: r252862 - head/usr.sbin Date: Sat, 6 Jul 2013 01:55:09 -0700 To: Devin Teske Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Devin Teske , "freebsd-rc@freebsd.org" X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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: Sat, 06 Jul 2013 08:55:15 -0000 On Jul 6, 2013, at 12:50 AM, Garrett Cooper wrote: > On Jul 5, 2013, at 11:05 PM, "Teske, Devin" wr= ote: >=20 >> On Jul 5, 2013, at 10:09 PM, Garrett Cooper wrote: >>=20 >>> On Jul 5, 2013, at 9:13 PM, Devin Teske wrote: >>>=20 >>>> Author: dteske >>>> Date: Sat Jul 6 04:13:47 2013 >>>> New Revision: 252862 >>>> URL: https://urldefense.proofpoint.com/v1/url?u=3Dhttp://svnweb.freebsd= .org/changeset/base/252862&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3DMrjs6= vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=3D6Emrz4%2BdiEiu3QIuKxkRkKl%2BdgggvTvDq79TFh= oaAC8%3D%0A&s=3Df8e3ea5c36067381ada1de66dd547b09eb051cd0761b399929dfa68851d0= ca37 >>>> Log: >>>> Take the training-wheels off, after nearly 30 months of development. MFC= to >>>> stable/9 planned after MFC 3-day period. The MFC to stable/9 is desired= for >>>> the next release to get some much-needed time: >>>> + Living side-by-side with sysinstall for compare/contrast/transition >>>> + Living side-by-side with bsdinstall for integration/transition >>>> + Additional feedback/testing before eventual 10.0-R to make it even be= tter >>>> MFC after: >>>> 3 days >>>=20 >>> Uh, why did you remove the conditional..? Why not just change the defaul= t from WITHOUT_BSDCONFIG to WITH_BSDCONFIG? >>>=20 >>> I don't need this necessarily on an already tuned system and this doesn'= t seem like something that should always be included on an appliance=81c >>=20 >> One plans was to use the libraries I'm bringing in to solve this PR: >>=20 >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dconf/163508 >> "[rc.subr] [patch] Add "enable" and "disable" commands to rc.subr" >>=20 >> The initial patch was rejected by dougb and I (as can be seen in the audi= t trail) because editing rc.conf(5) is not a simple proposition. bsdconfig(8= ) brings in a shell library called "sysrc.subr" (and the sysrc(8) utility le= verages it to provide all the nifty things it can do). The shell library is o= f interest if we want to implement the high-level concept from the PR: >>=20 >> sevice {name} { enable | disable | . . . } >>=20 >> Since sysrc.subr provides a simple "f_sysrc_set $var $value" syntax (I'll= leave the rest up to your imagination). >>=20 >> Staying on-topic, bsdconfig (or rather, its libraries) could end up entwi= ned to the shell commands and you may end up using it without ever directly e= xecuting "bsdconfig". >=20 > I'd like to read more about this. We (isilon) have hacked around rc(5) bec= ause the performance of rc is serialized and poor. I would prefer to avoid a= dding more end-user bloat to rc because it will drive users and consumers to= take more drastic measures to bypass the rc system. >=20 > Thanks.. Also, if the day comes where rc depends on bsdconfig, I hope that the pieces= of bsdconfig would potentially be moved to .../etc for the sake of "code lo= cality". Thanks!=