Re: Oops: ptrace fix buggy

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Mon, 14 April 2003 20:10:25 +0200, Martin Schlemmer wrote:
> 
> From include/linux/version.h:
> 
> ---------------------------------------------------------------
> #define UTS_RELEASE "2.5.67-bk2"
> #define LINUX_VERSION_CODE 132419
> #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
> ---------------------------------------------------------------
> 
> Your changes will definitely break things that do:
> 
> #if ((LINUX_VERSION_CODE > KERNEL_VERSION(2.4.0)) && \
>      (LINUX_VERSION_CODE < KERNEL_VERSION(2.5.0)))
> 
> Also, most docs explaining the version format, refer to
> 
>   major.minor.micro
> 
> Anyhow, I did not say it was set in stone, I just said if you
> start getting breakage when compiling/configuring things, do
> not wonder why =)

James Bourne:
> The problem comes in when you bump the FIXLEVEL for example, by one.  At
> that point the LINUX_VERSION_CODE would not change even though you have a
> new kernel and modules compiled for the previous version may not load or
> may load and not work correctly (just one example).
> 
> EXTRAVERSION on the other hand is not used for LINUX_VERSION_CODE
> calculation.

So basically, neither the existing EXTRAVERSION nor my new FIXLEVEL
are checked. Any code could potentially break with -ac1 to -ac2 or
with .1 to .2.

Did anyone experience such problems with -ac already? There are far
more changes in -ac than there are in your patch.

Driver compilation should not be an issue. Change the Makefile and
version.h should be changed as well, so any code depending on
version.h will be rebuild, whether necessary or not.

Module load sounds unrealistic for .[123...], as you shouldn't change
any interfaces with fixes. But it might be a real problem for -ac.

Jörn

PS: Or for -aa, -dj, -mm or whatever. It's just an example.

-- 
Do not stop an army on its way home.
-- Sun Tzu