Re: Linux 2.6.32-rc3

[Frans Pop <elendil@planet.nl>]

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