Re: [PATCH] Fancy rc startup (revisited)

On Sat, 12 May 2007, Steve Rikli wrote:

> On Sat, May 12, 2007 at 09:40:30PM -0500, Dan Nelson wrote:
>> In the last episode (May 12), Robert Watson said:
>>>  Call me old-fashioned, but I actually preferred the much more
>>>  abbreviated rc output from before rc.d even. :-) We're not going
>>>  back to hardware devices where all the probed devices add up to
>>>  fewer than 25 lines, I'm sure, but when daemons generated 8-12
>>>  characters without a carriage return each, there was a good chance
>>>  you could still see the end of the kernel messages by the time you
>>>  got to login:, and I miss that.  I don't object to optional more
>>>  complex output as long as that complexity is hidden away neatly
>>>  somewhere in rc.subr, and isn't on by default as shipped.  I'd love
>>>  it if someone could restore the even shorter output we had before.
>>
>> Taken to an extreme, you have Solaris 10, where you get the kernel's 
>> copyright message, smf kicks off all the startup scripts in parallel 
>> (subject to dependency rules) in the background, their output goes into 
>> individual logfiles, and all you see is the login: prompt at the console :)
>
> Right.  And near as I can tell, no easy way to control that behavior without 
> passing args to the kernel at boottime.  I think.  Which can be a bother 
> e.g. when you're trying to figure out what the thing is actually doing (or 
> trying to do), and you can't remember.  :)
>
> I can appreciate the above commentary about brevity, but in the absence of 
> "the one true boot message behavior", the ability to set e.g.
>
> boot_verbose=[YES|NO|MEDIUM]
>
> or similar notion in rc.conf might be good, if implement'able.

There are two places we could do this, and both isn't impossible either as 
they meet different requirements:

(1) rc.conf is the canonical place for configuring the rc.d boot parts, and
     it's easy to imagine how it all fits together.

(2) kernel environmental variables can be set in the boot loader before boot
     without having to have a mounted file system, and can be queried with
     kenv(1).

I think it would be useful to have an rc.conf variable and a kernel boot 
variable that is not set by default, and have the latter override the former 
if present.  All of this presupposes someone adding flexibility :-).

Robert N M Watson
Computer Laboratory
University of Cambridge