svn commit: r252862 - head/usr.sbin

[Teske, Devin]

On Jul 6, 2013, at 1:55 AM, Garrett Cooper wrote:

On Jul 6, 2013, at 12:50 AM, Garrett Cooper <yaneurabeya at gmail.com<mailto:yaneurabeya at gmail.com>> wrote:

On Jul 5, 2013, at 11:05 PM, "Teske, Devin" <Devin.Teske at fisglobal.com<mailto:Devin.Teske at fisglobal.com>> wrote:

On Jul 5, 2013, at 10:09 PM, Garrett Cooper wrote:

On Jul 5, 2013, at 9:13 PM, Devin Teske wrote:

Author: dteske
Date: Sat Jul  6 04:13:47 2013
New Revision: 252862
URL: https://urldefense.proofpoint.com/v1/url?u=http://svnweb.freebsd.org/changeset/base/252862&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=6Emrz4%2BdiEiu3QIuKxkRkKl%2BdgggvTvDq79TFhoaAC8%3D%0A&s=f8e3ea5c36067381ada1de66dd547b09eb051cd0761b399929dfa68851d0ca37

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 better

MFC after: 3 days

Uh, why did you remove the conditional..? Why not just change the default from WITHOUT_BSDCONFIG to WITH_BSDCONFIG?

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�


One plans was to use the libraries I'm bringing in to solve this PR:

http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/163508<https://urldefense.proofpoint.com/v1/url?u=http://www.freebsd.org/cgi/query-pr.cgi?pr%3Dconf/163508&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=rjZku6WmtVaEyBGo%2F6Bf9woxvhx8AIG%2BwFas9K%2BXMKU%3D%0A&s=58ee0a4ead6d75324bcf9f2d1d9c1d8ca1bb77a8d97c5251b801b5f830376a38>
"[rc.subr] [patch] Add "enable" and "disable" commands to rc.subr"

The initial patch was rejected by dougb and I (as can be seen in the audit 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 leverages it to provide all the nifty things it can do). The shell library is of interest if we want to implement the high-level concept from the PR:

sevice {name} { enable | disable | . . . }

Since sysrc.subr provides a simple "f_sysrc_set $var $value" syntax (I'll leave the rest up to your imagination).

Staying on-topic, bsdconfig (or rather, its libraries) could end up entwined to the shell commands and you may end up using it without ever directly executing "bsdconfig".

I'd like to read more about this. We (isilon) have hacked around rc(5) because the performance of rc is serialized and poor. I would prefer to avoid adding more end-user bloat to rc because it will drive users and consumers to take more drastic measures to bypass the rc system.

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 locality".


You read my playbook.

After bsdconfig has been MFC'd to 9, my plan was to (in HEAD), try out the following:


+ Moving /usr/share/bsdconfig/sysrc.subr to /etc
+ Changing all scripts/libraries of bsdconfig(8) to point at /etc/sysrc.subr
+ Changing sysrc(8) to point at /etc/sysrc.subr
+ Altering new /etc/sysrc.subr slightly to live without bsdconfig's "common.subr" (of which it used f_err() and f_quietly())

However, I would really like to see bsdconfig's "common.subr" get pulled back to /etc too.

That would mean that I could then take sysrc(8) and move from usr.sbin to sbin -- which would allow us to probe/modify rc.conf(5) with it in single-user mode.
--
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: <http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20130706/f5f11881/attachment.txt>