svn commit: r239598 - head/etc/rc.d

[Warner Losh]

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

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.
> 
> :-)
> 
>> 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 ___ && ___".

Since kenv is a bad source of entropy, I'm kinda guessing this is moot.

Warner