Re: Interesting article on boot ordering

[Kevin Worthington]

I remember that this was discussed on this list a while back. Specifically Serel, located at fastboot.org
Many of the Red Hat folks said it could be done, but was not really needed IIRC.
> http://www-106.ibm.com/developerworks/linux/library/l-boot.html

Interesting article on boot ordering

[Bill Nottingham]

Kevin Worthington ([e-mail]) said:
> I remember that this was discussed on this list a while back. Specifically Serel, located at fastboot.org
> Many of the Red Hat folks said it could be done, but was not really needed IIRC.

It's not that it's not really needed, it's that when it was tried it
didn't really help that much.

For example, we just in the past day or two got rid of 41 shell invocations
on boot just by changing how grep was built. Always look for the big wins
first. :)

Bill

Interesting article on boot ordering

[Chip Turner]

Bill Nottingham  writes:
> Kevin Worthington ([e-mail]) said:
> > I remember that this was discussed on this list a while back. Specifically Serel, located at fastboot.org
> > Many of the Red Hat folks said it could be done, but was not really needed IIRC.
>
> It's not that it's not really needed, it's that when it was tried it
> didn't really help that much.
>
> For example, we just in the past day or two got rid of 41 shell invocations
> on boot just by changing how grep was built. Always look for the big wins
> first. :)

Any numbers on how much faster it (and any other optimizations) have
made booting?  Any other approaches being tried to speed up booting?

Chip

Interesting article on boot ordering

[Bill Nottingham]

Chip Turner ([e-mail]) said:
> > It's not that it's not really needed, it's that when it was tried it
> > didn't really help that much.
> >
> > For example, we just in the past day or two got rid of 41 shell invocations
> > on boot just by changing how grep was built. Always look for the big wins
> > first. :)
>
> Any numbers on how much faster it (and any other optimizations) have
> made booting?

The grep change? I'm not sure, but it certainly can't make it slower.
I can run some tests at some point later.
> Any other approaches being tried to speed up booting?

There are suggestions made on bug #99540. There hasn't been much
implemenetation yet.

Bill

Interesting article on boot ordering

[Chris Adams]

Once upon a time, Bill Nottingham  said:
> For example, we just in the past day or two got rid of 41 shell invocations
> on boot just by changing how grep was built. Always look for the big wins
> first. :)

Yeah, I've got a bit in my standard profile script that strips out
instances of the "standard" directory from the path and re-adds them at
the beginning in a specified order (so you don't get duplicates, they
are in an expected order, etc.).  This used to take forever, but I
managed to make it run entirely with no external calls (including no
forks, no subshells, etc.).

########################################################################
# Set the base PATH here
BASEPATH=/usr/local/bin:/usr/bin:/bin
BASEPATH=$BASEPATH:/usr/X11R6/bin
BASEPATH=$BASEPATH:/usr/games
BASEPATH=$BASEPATH:/usr/local/sbin:/usr/sbin:/sbin
BASEPATH=$HOME/bin:$BASEPATH

# Split the base PATH and PATH into arrays for searching
IFS=":$IFS"
BASEARRAY=($BASEPATH)
PATHARRAY=($PATH)
IFS="${IFS#:}"

# Now remove any instances of the base PATH from the PATH and put them
# at the front
PATH=$BASEPATH
for pdir in ${PATHARRAY[*]}; do
    cont=0
    for bdir in ${BASEARRAY[*]}; do
    	if [ "$pdir" = "$bdir" ]; then
    		cont=1
    		break
    	fi
    done
    [ "$cont" = 1 ] && continue
    PATH="$PATH:$pdir"
done
unset BASEPATH BASEARRAY PATHARRAY pdir cont bdir
export PATH

########################################################################

The "BASEARRAY=($BASEPATH)" is a bash specific thing; the same effect
can be had in ksh with "set -A BASEARRAY $BASEPATH", but that is ksh
specific (I don't know of a POSIX shell way of doing that).

It seems like a little thing, but optimizing shell scripts can make a
big difference.