From owner-freebsd-rc@FreeBSD.ORG Fri Sep 7 01:31:13 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 637531065673 for ; Fri, 7 Sep 2012 01:31:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id AFEE28FC12 for ; Fri, 7 Sep 2012 01:31:12 +0000 (UTC) Received: by obbun3 with SMTP id un3so4696015obb.13 for ; Thu, 06 Sep 2012 18:31:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=OQZzq2ph1dz5kpEgW8Lb/mvLMHqC9u/kmtJ51DikN5c=; b=FhfcH44aLoIp/X5eOPlITiO0i1KvzO9IujaqpKxqNQ4n4szLj40MCKFwAbBWoUmJh8 Adm14nbiYPLPatCikigKC7b2Tt+0XASG3Iv2ecLah6/w3se28+c66ZmIwPDRa+iGbVC/ dDFHG2NcsH34PvN+yKC/YeLD21GHOn5W46OBwG5gxy0zUzW6f4+56A2yxtdTQdACf796 kuyoyaxV/7/I9y6pCvEkmPWu7SPmi0ukaqf4HjE4zfGr5gLUGcx3lCfzGn42yTQXEmn/ rLVQ8xFfsvZkiZyunC379OlgAqYi3aNZnysVllWQdq1/5FDrO5WrjyXDFtxMhUJJ21kJ WilA== Received: by 10.60.30.101 with SMTP id r5mr4186118oeh.68.1346981472224; Thu, 06 Sep 2012 18:31:12 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id a6sm2841827oeh.1.2012.09.06.18.31.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Sep 2012 18:31:11 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120906190239.GG13179@dragon.NUXI.org> Date: Thu, 6 Sep 2012 19:31:08 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1A362209-58C1-47A0-A10D-F68359051312@bsdimp.com> 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> <20120906190239.GG13179@dragon.NUXI.org> To: obrien@freebsd.org X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmx35gffRajlubwNB9UwB2fDvZj4e8V5OArV2b/HRcD+O0KZcVu28wmVcQA2sKr9AV62pYG Cc: Arthur Mesh , Doug Barton , freebsd-rc@freebsd.org, freebsd-security@freebsd.org, Mark Murray Subject: Re: svn commit: r239598 - head/etc/rc.d X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 07 Sep 2012 01:31:13 -0000 On Sep 6, 2012, at 1:02 PM, David O'Brien wrote: > 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. =20 >=20 > The FreeBSD kernel expects to be loaded by /boot/loader and for it to > provided a suitable environment. >=20 > 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. Really? I don't think so. Most of the ARM and MIPS ports can't be = loaded by /boot/loader, the notable exception being the Marvell ARM = stuff. And even if they were, they lack the code to get the metadata = blobs you need to recover the kenv. It is typical in the embedded space = not to be loaded by /boot/loader. Your gear from $WORK is atypical = here. Besides, kenv typically is static for any given machine, so is = not a good 'randomization' vector. >> 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. >=20 > :-) >=20 >> 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. >=20 > 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. >=20 > I don't want to see every command in better_than_nothing() turn into > "test -x ___ && ___". Since kenv is a bad source of entropy, I'm kinda guessing this is moot. Warner=