rc improvements (wanted?)
Peter Ross
Peter.Ross at alumni.tu-berlin.de
Sun Jul 20 10:29:42 UTC 2008
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)
> - 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.
> 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.
Regards
Peter
More information about the freebsd-current
mailing list