Re: MM kernels - how to keep on the bleeding edge?

[Michael Krufky <mkrufky@m1k.net>]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

Michael Krufky wrote:

> However, sometimes there are patches in -mm that are incompatable with 
> -linus.  An example of this is "Pavel's pm_message_t mangling" ... 
> Testing for the numbered 2.6.x version isn't enough of a test in a 
> case like this, but it would be nice to be able to develop against the 
> most recent version of both the -mm tree and the -linus tree without 
> having to revert patches.  Of course, v4l has chosen to maintain 
> compatibility with -mm, for the sake of patch generation, and I have a 
> handy -linus-compat.patch on the side for now if I want to build cvs 
> against -linus, until Pavel's patches get merged later on.  But I'm 
> sure things like this must happen all the time.  How do others deal 
> with issues like these automatically?
>
> It doesn't matter which -mm version or which -linus version it is... I 
> can already test for 2.6.x ... All that matters is if it is -mm or 
> -linus.  If there isn't already an answer to this question, maybe you 
> can create a /linux/.mm file, or something like that.  A Makefile can 
> test for the presence of that file... or is there already a file 
> present that is unique to the -mm tree?
>
Here's a patch, if you so choose to go this route.....

This should NEVER be merged to -linus ;-)

Signed-off-by: Michael Krufky <mkrufky@m1k.net>




[-- Attachment #2: mm-only.patch --]
[-- Type: text/plain, Size: 131 bytes --]

diff -upN a/.mm b/.mm
--- a/.mm	1970-01-01 00:00:00.000000000 +0000
+++ b/.mm	2005-07-26 20:57:41.000000000 +0000
@@ -0,0 +1 @@
+1