cvs commit: src/etc rc.subr src/share/man/man8 rc.subr.8

[Yar Tikhiy]

On Wed, Jun 21, 2006 at 12:05:09PM +0100, Florent Thoumie wrote:
> On Wed, 2006-06-21 at 14:52 +0400, Yar Tikhiy wrote:
> > On Wed, Jun 21, 2006 at 10:56:25AM +0100, Florent Thoumie wrote:
> > > On Wed, 2006-06-21 at 09:42 +0000, Yar Tikhiy wrote:
> > > > yar         2006-06-21 09:42:55 UTC
> > > > 
> > > >   FreeBSD src repository
> > > > 
> > > >   Modified files:
> > > >     etc                  rc.subr 
> > > >     share/man/man8       rc.subr.8 
> > > >   Log:
> > > >   Quite a number of rc.d scripts try to load kernel modules.  Many
> > > >   of them do that conditionally depending on kldstat.  The code is
> > > >   duplicated all over, but bugs can be uniqie.
> > > >   
> > > >   To make the things more consistent, introduce a new rc.subr function,
> > > >   load_kld, which takes care of loading a kernel module conditionally.
> > > >   
> > > >   (Found this lying for a while in my p4 branch for various hacks.)
> > > 
> > > I added such a function some weeks ago (far more simple though). Talking
> > > with pjd, I've backed it out to use the somewhat straight-forward method
> > > he used in rc.d/geli.
> > 
> > rc.d/geli doesn't use kldload directlty, so it certainly won't
> > benefit from the function I introduced.
> 
> Then I'm not sure what script would benefit from this function. Can you
> point me to an example?

abi
archdep
atm1
hcsecd
ipfilter
mdconfig
mdconfig2
pf
pflog
pfsync
sdpd
syscons

They all do kldstat then kldload.  Some of them do grep or egrep
on kldstat output.  Some of them don't forget to check status from
kldload and emit a error message on failure.  Besides, there are
scripts that forget to do kldstat in the first place, they just do
kldload.  Now all this ado can become just a call to my function.

> > > I don't have a particular feeling against your function but it uses
> > > commands that may not be available early enough (getopt, egrep). While
> > > it's easy to remove the getopt dependency (see rc.d/mdconfig), it's not
> > > the case for egrep.
> > 
> > It's POSIX getopts, which ought to be a shell built-it by its design.
> > egrep is used with -e only, one can avoid using it if egrep isn't
> > available yet.  The only issue is true and false, I was sure they
> > were in /bin, but it can be fixed easily.

As I've just found, we have true and false as undocumented sh(1)
builtins from the beginning of times.  So using true and false is
no issue in rc.subr either.

> Still, with /bin/sh, getopt isn't a builtin:
> 
> $ sh -c 'which getopt'
> /usr/bin/getopt

You still mistake my words.  It's getopts, not getopt.  See sh(1).

> You won't gain anything using grep instead of egrep since they're both
> in /usr/bin.

Have I ever tried to?

-- 
Yar