Re: rc improvements (wanted?)

> On Sun, 20 Jul 2008, Danny Braniss wrote:
> 
> > I went ahead with my idea - to reduce the list rcorder delivers, by 
> > eliminating those that don't have ${name}_enable, and I opened a pandora 
> > box :-)
> >   - dummy dependency like SERVERS/LOGIN don't have ${name}_enable
> >     nor should have.
> 
> Two options:
> - Just eliminate the scripts that have the variable, and set it to "no"
> - A dummy entry in /etc/defaults/rc.conf with "# Don't overwrite this"
>   (So only one who really knows what he is doing will try it - hopefully)
> 
as usual I forgot one word, 
	don't have ${name}_enable
should have been:
	don't have ${name}_enable="YES"  (or true or 1)

personaly, I prefer self-contained, like 
	iscsi_enable=${iscsi_enable:-"NO"}
instead of adding it to /etc/defaults/rc.conf, though I can see the benefit.
what I'm trying to say, is keep the complexity to a minimum, less 
foot-shooting :-)

> >   - REQUIERE: xxx complains if xxx is not 'loaded' like in the case
> >     of NETWORKING requirement of ppp which I don't have enabled.
> 
> Solved by point 1?
> 
> >   - some scripts rely on the existance of a ${file} which is better than
> >     the original /etc/rc which used to run mountd if /etc/exports existed,
> >     but does not 'conform' to the ${name}_enable paradigm.
> 
> The same?
> 
> >   - some scripts like abi don't have abi_enable, but sysvipc_enable,
> >     linux_enable and svr4_enable.
> 
> I looked at this. abi is in fact a container for three start scripts.
> 
> Of course splitting them makes the situation worse..
> 
> If the ${name}_enable check becomes a function
> some special cases could be treated in a case statement
> 
> case ${name} of
>    mountd)
>       if [ -f /etc/exports ]; then result=1; fi
>       ;;
>    abi)
>       if [ checkyesno sysvipc -o checkyesno linux_enable .. ]; then
>          result=1; fi
>       ;;
>    *)
>       enable=eval \$${name}_enable
>       if [ "X${enable}" = "X" ]; then result=1
>       else result=`checkyesno ${enable}`; fi
>       ;;
> esac
> 
> [That's untested demo code and may contain typos]
> 
> Unfortunately the rc.d scripts are not self-contained anymore. That may 
> offend some. But there is shared *.subr code already.
> 

the initial idea behind rcng (was it called like that?), was, and most of it
is still good, it's nicer that the monolithick /etc/rc of old, and less messy 
than
sys5's. lets try and keep it 'simple' - as usual the KISS principle has
more than one interpretation :-)

> > All these - and some more that I probably missed - can be fixed, or the 
> > warnings ignored, but is it worthwhile?
> 
> That's a good question. It is up to the users of "slower" hardware 
> (e.g.embedded devices), I think.
> 

yup, on the other hand, servers take so long to boot nowadays, that speeding up
rc, IMHO, wont make a difference, or even if it's fast, a fsck that's running 
in
the background will slow the host anyways :-).

> Regards
> Peter

cheers,
	danny