Re: Linux 2.6.32-rc3

Frans Pop
2009-10-15T15:51:41Z

Ingo Molnar wrote:
> hm, i think you ignored (or missed, or found irrelevant) my first
> suggested variant:
>
> v2.6.31
> v2.6.31+

A general concern about adding the "+".

Anyone want to bet how many (init?) scripts there are in userspace that do
something like:

KVERS="$(uname -r | cut -d"-" -f1)"
case $KVERS in
2.6.*)
minor=$(echo $KVERS | cut -d"." -f3)
if [ $minor -lt 10 ]; then
# do something
fi ;;
esac

Note that the '[ $minor -lt 10 ]' will now produce an error because
'31+' is no longer a valid number:
bash: [: 31+: integer expression expected

A "-" has for ages been the standard separator between the kernel version
and any suffixes, certainly in Debian. Loads of scripts will assume that.

In an earlier mail I said that I would consider using the "+". This is
seriously making me have second thoughts, even for custom built kernels.

Here are some real life examples from my Debian stable system:
/etc/init.d/pcmciautils:
supported_kernel()
{
case $KERNEL_VERSION in
2.[012345].*|2.6.[0-9]|2.6.[0-9][!0-9]*) return 1 ;;
2.6.1[012]|2.6.1[012][!0-9]*) return 1 ;;
esac
return 0
}

Would have failed for e.g. a 2.6.12+ kernel.

/etc/init.d/umountnfs.sh:
KERNEL="$(uname -s)"
RELEASE="$(uname -r)"
case "${KERNEL}:${RELEASE}" in
Linux:[01].*|Linux:2.[01].*)
FLAGS=""
;;
Linux:2.[23].*|Linux:2.4.?|Linux:2.4.?-*|Linux:2.4.10|Linux:2.4.10-*)
FLAGS="-f"
;;
*)
FLAGS="-f -l"
;;
esac

Would have failed for e.g. a 2.4.7+ kernel.

Sure, these won't fail if we start adding the "+" now, but will the people
writing such tests in the future always remember to allow for the "+",
especially given that it will be relatively rare in a distro context?

Cheers,
FJP