From owner-freebsd-rc@FreeBSD.ORG Thu Sep 6 19:02:40 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 4E0B7106567B; Thu, 6 Sep 2012 19:02:40 +0000 (UTC) Date: Thu, 6 Sep 2012 12:02:39 -0700 From: David O'Brien To: Ian Lepore Message-ID: <20120906190239.GG13179@dragon.NUXI.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120906164514.GA14757@dragon.NUXI.org> <1346951961.59094.158.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1346951961.59094.158.camel@revolution.hippie.lan> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@freebsd.org, Mark Murray , Doug Barton , freebsd-rc@freebsd.org Subject: Re: svn commit: r239598 - head/etc/rc.d X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org 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: Thu, 06 Sep 2012 19:02:40 -0000 On Thu, Sep 06, 2012 at 11:19:21AM -0600, Ian Lepore wrote: > The kenv application may be available, but on any platform that > lacks /boot/loader it's likely to produce empty output. Because the > kernel environment is typically empty, an embedded system may not even > have the kenv binary installed. The FreeBSD kernel expects to be loaded by /boot/loader and for it to provided a suitable environment. If one has chosen to not use /boot/loader (or include 'kenv' on their embedded boot media), they're already gone so far down the path of customization that hacking 'initrandom' should be expected. > I should note that I don't think the needs of embedded systems should > carry so much weight in this discussion that it leads to jumping through > major hoops. :-) > I think the most important point would be "Let failures be > soft ones" -- things you may think of as basic tools always available on > a minimal installation may not be there on a stripped down embedded > system; no big deal, just don't hang the system or anything else dire in > that case. I think that just adds to needless cruft in /etc/rc.d scripts that is hard to test and keep working -- as committers will 99.9999% time be in a full FreeBSD environment. I don't want to see every command in better_than_nothing() turn into "test -x ___ && ___". -- -- David (obrien@FreeBSD.org)