Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Sep 2012 19:31:08 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        obrien@freebsd.org
Cc:        Arthur Mesh <arthurmesh@gmail.com>, Doug Barton <dougb@freebsd.org>, freebsd-rc@freebsd.org, freebsd-security@freebsd.org, Mark Murray <markm@freebsd.org>
Subject:   Re: svn commit: r239598 - head/etc/rc.d
Message-ID:  <1A362209-58C1-47A0-A10D-F68359051312@bsdimp.com>
In-Reply-To: <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> <20120906190239.GG13179@dragon.NUXI.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1A362209-58C1-47A0-A10D-F68359051312>