Linux 2.6.11.2

Linux 2.6.11.2

[Greg KH]

And to further test this whole -stable system, I've released 2.6.11.2.
It contains one patch, which is already in the -bk tree, and came from
the security team (hence the lack of the longer review cycle).

It's available now in the normal kernel.org places:
	kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
which is a patch against the 2.6.11.1 release.  If consensus arrives
that this patch should be against the 2.6.11 tree, it will be done that
way in the future.

A detailed changelog can be found at:
 	kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.11.2

A bitkeeper tree for the 2.6.11.y releases can be found at:
	bk://linux-release.bkbits.net/linux-2.6.11

The diffstat and short summary of the fixes are below.  

I'll also be replying to this message with a copy of the patch itself,
as it is small enough to do so.

thanks,
 
greg k-h

-------


 Makefile       |    2 +-
 fs/eventpoll.c |    3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)


Summary of changes from v2.6.11.1 to v2.6.11.2
============================================

Greg Kroah-Hartman:
  o Linux 2.6.11.2

Linus Torvalds:
  o epoll: return proper error on overflow condition

Re: Linux 2.6.11.2

[Greg KH]

diff -Nru a/Makefile b/Makefile
--- a/Makefile	2005-03-09 00:13:29 -08:00
+++ b/Makefile	2005-03-09 00:13:29 -08:00
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 11
-EXTRAVERSION = .1
+EXTRAVERSION = .2
 NAME=Woozy Numbat
 
 # *DOCUMENTATION*
diff -Nru a/fs/eventpoll.c b/fs/eventpoll.c
--- a/fs/eventpoll.c	2005-03-09 00:13:29 -08:00
+++ b/fs/eventpoll.c	2005-03-09 00:13:29 -08:00
@@ -619,6 +619,7 @@
 	return error;
 }
 
+#define MAX_EVENTS (INT_MAX / sizeof(struct epoll_event))
 
 /*
  * Implement the event wait interface for the eventpoll file. It is the kernel
@@ -635,7 +636,7 @@
 		     current, epfd, events, maxevents, timeout));
 
 	/* The maximum number of event must be greater than zero */
-	if (maxevents <= 0)
+	if (maxevents <= 0 || maxevents > MAX_EVENTS)
 		return -EINVAL;
 
 	/* Verify that the area passed by the user is writeable */

Re: Linux 2.6.11.2

[Gene Heskett]

On Wednesday 09 March 2005 03:39, Greg KH wrote:
>diff -Nru a/Makefile b/Makefile
>--- a/Makefile 2005-03-09 00:13:29 -08:00
>+++ b/Makefile 2005-03-09 00:13:29 -08:00
>@@ -1,7 +1,7 @@
> VERSION = 2
> PATCHLEVEL = 6
> SUBLEVEL = 11
>-EXTRAVERSION = .1
>+EXTRAVERSION = .2
> NAME=Woozy Numbat
>
> # *DOCUMENTATION*
>diff -Nru a/fs/eventpoll.c b/fs/eventpoll.c
>--- a/fs/eventpoll.c 2005-03-09 00:13:29 -08:00
>+++ b/fs/eventpoll.c 2005-03-09 00:13:29 -08:00
>@@ -619,6 +619,7 @@
>  return error;
> }
>
>+#define MAX_EVENTS (INT_MAX / sizeof(struct epoll_event))
>
> /*
>  * Implement the event wait interface for the eventpoll file. It is
> the kernel @@ -635,7 +636,7 @@
>        current, epfd, events, maxevents, timeout));
>
>  /* The maximum number of event must be greater than zero */
>- if (maxevents <= 0)
>+ if (maxevents <= 0 || maxevents > MAX_EVENTS)
>   return -EINVAL;
>
>  /* Verify that the area passed by the user is writeable */
>-

Greg, I have now pretty well confirmed that this patch is what caused 
the tvtime audio breakage I was observing here.  Rebooting to 
2.6.11.1, everything works, rebooting to 2.6.11.2, and its broken.  
ditto for .3 and .4, so last night I built a .5 (had to patch the 
Makefiles EXTRAVERSION & rebuild before it would boot after the 
build) but I built it *without* this patch, and everything works.

This patch looks good to me except for the added MAX_EVENTS define.  
Did anyone actually put in a printk at that point and see what 
MAX_EVENTS actually was by that define?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: Linux 2.6.11.2

[Marcos D. Marado Torres]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 9 Mar 2005, Greg KH wrote:

> which is a patch against the 2.6.11.1 release.  If consensus arrives
> that this patch should be against the 2.6.11 tree, it will be done that
> way in the future.

IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt againt
the last -rc but against 2.6.x.

Marcos Marado

- -- 
/* *************************************************************** */
    Marcos Daniel Marado Torres	     AKA	Mind Booster Noori
    http://student.dei.uc.pt/~marado   -	  marado@student.dei.uc.pt
    () Join the ASCII ribbon campaign against html email, Microsoft
    /\ attachments and Software patents.   They endanger the World.
    Sign a petition against patents:  http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFCLsdwmNlq8m+oD34RApSIAJ4rAaaDduX7Xp1ChqGj9KJkqg/HuwCfYb5X
5UAEW4srRcpOqspM8JaScAM=
=REDu
-----END PGP SIGNATURE-----

Re: Linux 2.6.11.2

[Geert Uytterhoeven]

On Wed, 9 Mar 2005, Marcos D. Marado Torres wrote:
> On Wed, 9 Mar 2005, Greg KH wrote:
> > which is a patch against the 2.6.11.1 release.  If consensus arrives
> > that this patch should be against the 2.6.11 tree, it will be done that
> > way in the future.
> 
> IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
> againt
> the last -rc but against 2.6.x.

It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most logical to
me.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Linux 2.6.11.2

[Marcos D. Marado Torres]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 9 Mar 2005, Geert Uytterhoeven wrote:

>>> which is a patch against the 2.6.11.1 release.  If consensus arrives
>>> that this patch should be against the 2.6.11 tree, it will be done that
>>> way in the future.
>>
>> IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
>> againt
>> the last -rc but against 2.6.x.
>
> It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most logical to
> me.

Well, yes, _if_ 2.6.12 patch is going to be to aply against 2.6.11.last instead
of 2.6.11. And, well, either one will cause great panic for hose who aren't and
the mailing lists and just visit kernel.org to downoad the latest stuff.

Marado

- -- 
/* *************************************************************** */
    Marcos Daniel Marado Torres	     AKA	Mind Booster Noori
    http://student.dei.uc.pt/~marado   -	  marado@student.dei.uc.pt
    () Join the ASCII ribbon campaign against html email, Microsoft
    /\ attachments and Software patents.   They endanger the World.
    Sign a petition against patents:  http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFCLs0rmNlq8m+oD34RAk+0AJsFwRyZ7vF9cE9thGYs/QjiVIjwjgCfclMR
nopc5sBPVauXqQCUeMxjYlM=
=YlzR
-----END PGP SIGNATURE-----

Re: Linux 2.6.11.2

[Geert Uytterhoeven]

On Wed, 9 Mar 2005, Marcos D. Marado Torres wrote:
> On Wed, 9 Mar 2005, Geert Uytterhoeven wrote:
> > > > which is a patch against the 2.6.11.1 release.  If consensus arrives
> > > > that this patch should be against the 2.6.11 tree, it will be done that
> > > > way in the future.
> > > 
> > > IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
> > > againt
> > > the last -rc but against 2.6.x.
> > 
> > It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most logical
> > to
> > me.
> 
> Well, yes, _if_ 2.6.12 patch is going to be to aply against 2.6.11.last
> instead
> of 2.6.11. And, well, either one will cause great panic for hose who aren't
> and
> the mailing lists and just visit kernel.org to downoad the latest stuff.

Probably the 2.6.12 patch will be against 2.6.11, since:
  - The 2.6.11.x line may continue after 2.6.12 was released
  - 2.6.11.x may contain `quick and dirty' fixes for problems, which will be
    fixed `properly' in 2.6.12 (or later), cfr. Alan Cox' presentation at
    FOSDEM.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Linux 2.6.11.2

[Jesper Juhl]

On Wed, 9 Mar 2005, Geert Uytterhoeven wrote:

> On Wed, 9 Mar 2005, Marcos D. Marado Torres wrote:
> > On Wed, 9 Mar 2005, Geert Uytterhoeven wrote:
> > > > > which is a patch against the 2.6.11.1 release.  If consensus arrives
> > > > > that this patch should be against the 2.6.11 tree, it will be done that
> > > > > way in the future.
> > > > 
> > > > IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
> > > > againt
> > > > the last -rc but against 2.6.x.
> > > 
> > > It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most logical
> > > to
> > > me.
> > 
> > Well, yes, _if_ 2.6.12 patch is going to be to aply against 2.6.11.last
> > instead
> > of 2.6.11. And, well, either one will cause great panic for hose who aren't
> > and
> > the mailing lists and just visit kernel.org to downoad the latest stuff.
> 
> Probably the 2.6.12 patch will be against 2.6.11, since:
>   - The 2.6.11.x line may continue after 2.6.12 was released
>   - 2.6.11.x may contain `quick and dirty' fixes for problems, which will be
>     fixed `properly' in 2.6.12 (or later), cfr. Alan Cox' presentation at
>     FOSDEM.
> 
Would it be that hard to have scripts on kernel.org generate the diff 
against 2.6.11 when Greg puts up the 2.6.11.3 diff against 2.6.22.2, then 
have the front page have two links, one for patch against 2.6.11 and one 
for patch against previous 2.6.11.z ?  That along with the full source 
(which I see is up there already) should make everyone happy, and if it is 
automated the burden on Greg should be minimal.


-- 
Jesper Juhl

Re: Linux 2.6.11.2

[Wakko Warner]

Marcos D. Marado Torres wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 9 Mar 2005, Geert Uytterhoeven wrote:
> 
> >>>which is a patch against the 2.6.11.1 release.  If consensus arrives
> >>>that this patch should be against the 2.6.11 tree, it will be done that
> >>>way in the future.
> >>
> >>IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
> >>againt
> >>the last -rc but against 2.6.x.
> >
> >It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most 
> >logical to
> >me.
> 
> Well, yes, _if_ 2.6.12 patch is going to be to aply against 2.6.11.last 
> instead
> of 2.6.11. And, well, either one will cause great panic for hose who aren't 
> and
> the mailing lists and just visit kernel.org to downoad the latest stuff.

<mode="enduser">
IMHO, as long as 2.6.12 patches against 2.6.11, I'm cool with 2.6.11.2
patching against 2.6.11.1, but I think it should patch against 2.6.11
instead
</mode>

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: Linux 2.6.11.2

[Dominik Karall]

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

On Wednesday 09 March 2005 11:04, Geert Uytterhoeven wrote:
> On Wed, 9 Mar 2005, Marcos D. Marado Torres wrote:
> > On Wed, 9 Mar 2005, Greg KH wrote:
> > > which is a patch against the 2.6.11.1 release.  If consensus arrives
> > > that this patch should be against the 2.6.11 tree, it will be done that
> > > way in the future.
> >
> > IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
> > againt
> > the last -rc but against 2.6.x.
>
> It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most
> logical to me.
>
> Gr{oetje,eeting}s,
>
> 						Geert

I don't think so. The latest patch (2.6.11.2 now) is on the frontpage of 
kernel.org, so IMHO the user should not need to search the kernel.org/pub 
archives to get 2.6.11.1 patch before he can start working with 2.6.11.2.

I think it's a small problem too, that 2.6.11 source isn't directly accessable 
through the kernel.org frontpage while there is no "full tarball" of 2.6.11.X 
trees.

greetings,
	dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]

Re: Linux 2.6.11.2

[Marcos D. Marado Torres]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 9 Mar 2005, Dominik Karall wrote:

>>>> which is a patch against the 2.6.11.1 release.  If consensus arrives
>>>> that this patch should be against the 2.6.11 tree, it will be done that
>>>> way in the future.
>>>
>>> IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
>>> againt
>>> the last -rc but against 2.6.x.
>>
>> It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most
>> logical to me.
>
> I don't think so. The latest patch (2.6.11.2 now) is on the frontpage of
> kernel.org, so IMHO the user should not need to search the kernel.org/pub
> archives to get 2.6.11.1 patch before he can start working with 2.6.11.2.
>
> I think it's a small problem too, that 2.6.11 source isn't directly accessable
> through the kernel.org frontpage while there is no "full tarball" of 2.6.11.X
> trees.

With that "full tarball" for 2.6.11.X the issues would be over.
I think there should be one.

Marado

- -- 
/* *********************************************************** */
    Marcos Daniel Marado Torres     AKA      Mind Booster Noori
    http://student.dei.uc.pt/~marado  -	 marado@magicbrain.biz
    () 	Join the ASCII ribbon campaign against HTML e-mail and
    /\ 	Microsoft attachments.        They endanger the World.
/* *********************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFCLs/gmNlq8m+oD34RAnu6AJwOvkvet1kLLGzLQ5EGuiVxtNbeEQCg7Ar9
Stnv4wmM74a5mX3fFrAh34Y=
=fCVH
-----END PGP SIGNATURE-----

Re: Linux 2.6.11.2

[Adrian Bunk]

On Wed, Mar 09, 2005 at 10:28:32AM +0000, Marcos D. Marado Torres wrote:
> 
> With that "full tarball" for 2.6.11.X the issues would be over.
> I think there should be one.

It's already there....

> Marado

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.11.2

[Greg KH]

On Wed, Mar 09, 2005 at 10:28:32AM +0000, Marcos D. Marado Torres wrote:
> On Wed, 9 Mar 2005, Dominik Karall wrote:
> 
> >>>> which is a patch against the 2.6.11.1 release.  If consensus arrives
> >>>> that this patch should be against the 2.6.11 tree, it will be done that
> >>>> way in the future.
> >>>
> >>> IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
> >>> againt
> >>> the last -rc but against 2.6.x.
> >>
> >> It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most
> >> logical to me.
> >
> > I don't think so. The latest patch (2.6.11.2 now) is on the frontpage of
> > kernel.org, so IMHO the user should not need to search the kernel.org/pub
> > archives to get 2.6.11.1 patch before he can start working with 2.6.11.2.
> >
> > I think it's a small problem too, that 2.6.11 source isn't directly accessable
> > through the kernel.org frontpage while there is no "full tarball" of 2.6.11.X
> > trees.
> 
> With that "full tarball" for 2.6.11.X the issues would be over.
> I think there should be one.

There is one, did you not look?

	kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.2.tar.gz

thanks,

greg k-h

Re: Linux 2.6.11.2

[Pavel Machek]

On St 09-03-05 09:52:46, Marcos D. Marado Torres wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 9 Mar 2005, Greg KH wrote:
> 
> >which is a patch against the 2.6.11.1 release.  If consensus arrives
> >that this patch should be against the 2.6.11 tree, it will be done that
> >way in the future.
> 
> IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt 
> againt
> the last -rc but against 2.6.x.

You expect people to go through all 2.6.11.1, 2.6.11.2, ... . That
means .11.2 should be relative to .11.1, because otherwise people will
have to revert (ugly). And you want people to track -stable kernels as
fast as possible.

So Greg did it right.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: Linux 2.6.11.2

[Matt Mackall]

On Wed, Mar 09, 2005 at 12:11:02PM +0100, Pavel Machek wrote:
> On St 09-03-05 09:52:46, Marcos D. Marado Torres wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On Wed, 9 Mar 2005, Greg KH wrote:
> > 
> > >which is a patch against the 2.6.11.1 release.  If consensus arrives
> > >that this patch should be against the 2.6.11 tree, it will be done that
> > >way in the future.
> > 
> > IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt 
> > againt
> > the last -rc but against 2.6.x.
> 
> You expect people to go through all 2.6.11.1, 2.6.11.2, ... . That
> means .11.2 should be relative to .11.1, because otherwise people will
> have to revert (ugly). And you want people to track -stable kernels as
> fast as possible.

There are three ways we can do this:

a) all 2.6.x.y are diffs against 2.6.x
b) interdiffs for .1, .2, etc. with 2.6.x+1 diffed against 2.6.x
c) interdiffs and 2.6.12 is a diff against 2.6.11.last

Imagine we want to go from 2.6.11.3 to 2.6.12

case a)
revert patch 2.6.11.3
get and apply 2.6.12

case b)
revert patch 2.6.11.3
revert patch 2.6.11.2
revert patch 2.6.11.1
get and apply 2.6.12

case c)
poke around on kernel.org and figure out that the last kernel in .11 is .11.5
get and apply 2.6.11.4
get and apply 2.6.11.5
get and apply 2.6.12

Note this gets increasingly more painful in cases b and c when there
are a large number of post-releases. And case c) is really stupid when
you want to go from 2.6.12 to 2.6.11.

Also note that -pre, -rc, -bk, -mm, -ac, and every other branch off a
release has worked the a) way.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Linux 2.6.11.2

[Willy Tarreau]

On Wed, Mar 09, 2005 at 03:57:16PM -0800, Matt Mackall wrote:
 
> Imagine we want to go from 2.6.11.3 to 2.6.12

The easiest way would be to keep a local fresh copy of 2.6.11 before
applying 2.6.11.3 anyway.  That would solve a) and b) even more easily.
And yes, I find a) more logical. This is the way all private trees have
been working for ages. When you download 2.6.11-ac2, it's not a patch
against -ac1, but against 2.6.11. If you want to start from -ac1, you
get the 2.6.11-ac1-ac2 patch.

And last, since these patches are mostly bugfixes for the reference kernel
(eg: 2.6.11), it seems logical to be able to patch that kernel with the
latest bug fix.

cheers,
willy

> case a)
> revert patch 2.6.11.3
> get and apply 2.6.12
> 
> case b)
> revert patch 2.6.11.3
> revert patch 2.6.11.2
> revert patch 2.6.11.1
> get and apply 2.6.12
> 
> case c)
> poke around on kernel.org and figure out that the last kernel in .11 is .11.5
> get and apply 2.6.11.4
> get and apply 2.6.11.5
> get and apply 2.6.12
> 
> Note this gets increasingly more painful in cases b and c when there
> are a large number of post-releases. And case c) is really stupid when
> you want to go from 2.6.12 to 2.6.11.
> 
> Also note that -pre, -rc, -bk, -mm, -ac, and every other branch off a
> release has worked the a) way.
> 
> -- 
> Mathematics is the supreme nostalgia of our time.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.11.2

[Bill Davidsen]

Matt Mackall wrote:
> On Wed, Mar 09, 2005 at 12:11:02PM +0100, Pavel Machek wrote:
> 
>>On St 09-03-05 09:52:46, Marcos D. Marado Torres wrote:
>>
>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
>>>
>>>On Wed, 9 Mar 2005, Greg KH wrote:
>>>
>>>
>>>>which is a patch against the 2.6.11.1 release.  If consensus arrives
>>>>that this patch should be against the 2.6.11 tree, it will be done that
>>>>way in the future.
>>>
>>>IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt 
>>>againt
>>>the last -rc but against 2.6.x.
>>
>>You expect people to go through all 2.6.11.1, 2.6.11.2, ... . That
>>means .11.2 should be relative to .11.1, because otherwise people will
>>have to revert (ugly). And you want people to track -stable kernels as
>>fast as possible.
> 
> 
> There are three ways we can do this:
> 
> a) all 2.6.x.y are diffs against 2.6.x
> b) interdiffs for .1, .2, etc. with 2.6.x+1 diffed against 2.6.x
> c) interdiffs and 2.6.12 is a diff against 2.6.11.last
> 
> Imagine we want to go from 2.6.11.3 to 2.6.12
> 
> case a)
> revert patch 2.6.11.3
> get and apply 2.6.12

Would anyone actually do that? About the time of the first patch usually 
do something like:
   cd linux-2.6.11
   cp -rl . ../linux-2.6.11.1
   cd $_
   bzcat ../Patches/patch-2.6.11.1.bz2 | patch -p1
   make oldconfig

By doing copy with links for all unchanged files you use virtually no 
extra space for each revision, and that encourages creating a separate 
tree for testing patches from -ck, or -ac, or Nick.

I use it to compile with various options as well, I usually build test 
versions for P-II, P-III, P4-HT and Athlon depending on what I'm testing.


-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Linux 2.6.11.2

[Matt Mackall]

On Fri, Mar 11, 2005 at 01:45:46PM -0500, Bill Davidsen wrote:
> Matt Mackall wrote:
> >On Wed, Mar 09, 2005 at 12:11:02PM +0100, Pavel Machek wrote:
> >
> >>On St 09-03-05 09:52:46, Marcos D. Marado Torres wrote:
> >>
> >>>-----BEGIN PGP SIGNED MESSAGE-----
> >>>Hash: SHA1
> >>>
> >>>On Wed, 9 Mar 2005, Greg KH wrote:
> >>>
> >>>
> >>>>which is a patch against the 2.6.11.1 release.  If consensus arrives
> >>>>that this patch should be against the 2.6.11 tree, it will be done that
> >>>>way in the future.
> >>>
> >>>IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt 
> >>>againt
> >>>the last -rc but against 2.6.x.
> >>
> >>You expect people to go through all 2.6.11.1, 2.6.11.2, ... . That
> >>means .11.2 should be relative to .11.1, because otherwise people will
> >>have to revert (ugly). And you want people to track -stable kernels as
> >>fast as possible.
> >
> >
> >There are three ways we can do this:
> >
> >a) all 2.6.x.y are diffs against 2.6.x
> >b) interdiffs for .1, .2, etc. with 2.6.x+1 diffed against 2.6.x
> >c) interdiffs and 2.6.12 is a diff against 2.6.11.last
> >
> >Imagine we want to go from 2.6.11.3 to 2.6.12
> >
> >case a)
> >revert patch 2.6.11.3
> >get and apply 2.6.12
> 
> Would anyone actually do that? About the time of the first patch usually 
> do something like:
>   cd linux-2.6.11
>   cp -rl . ../linux-2.6.11.1
>   cd $_
>   bzcat ../Patches/patch-2.6.11.1.bz2 | patch -p1
>   make oldconfig

In your world, do you want to do:

cp -rl linux-2.6.11 linux-2.6.11.5
cd linux-2.6.11.5
bzcat ../Patches/patch-2.6.11.1.bz2 | patch -p1
bzcat ../Patches/patch-2.6.11.2.bz2 | patch -p1
bzcat ../Patches/patch-2.6.11.3.bz2 | patch -p1
bzcat ../Patches/patch-2.6.11.4.bz2 | patch -p1
bzcat ../Patches/patch-2.6.11.5.bz2 | patch -p1

I suspect you might find that tedious, especially if only the last one
addressed a bug that affected you.

Or do you want to do it the same way you do for every other branch? I
don't want to special-case it in my code and I don't think users want
to special-case it in their brains. Have separate interdiffs on the
side, please, and then people can choose, but do it the standard way.

Dear ${SUCKER}s, can we have a decision on this? My ketchup tool is
broken for 2.6.11.2 and I don't want to cut a new release until a firm
decision is made. Obviously I have a strong preference for all 2.6.x.y
diffs being against 2.6.x, it means that .y can be treated the same as
-rc, -bk, -mm, ... (and I already coded it that way when 2.6.8.1 came
out).

-- 
Mathematics is the supreme nostalgia of our time.

Re: Linux 2.6.11.2

[Chris Wright]

* Matt Mackall (mpm@selenic.com) wrote:
> Or do you want to do it the same way you do for every other branch? I
> don't want to special-case it in my code and I don't think users want
> to special-case it in their brains. Have separate interdiffs on the
> side, please, and then people can choose, but do it the standard way.
> 
> Dear ${SUCKER}s, can we have a decision on this? My ketchup tool is
> broken for 2.6.11.2 and I don't want to cut a new release until a firm
> decision is made. Obviously I have a strong preference for all 2.6.x.y
> diffs being against 2.6.x, it means that .y can be treated the same as
> -rc, -bk, -mm, ... (and I already coded it that way when 2.6.8.1 came
> out).

I agree with having the patch be against .x, with x.y -> x.y+1 interdiffs
available on the side.  Greg, any issue with that?

thanks,
-chris

Re: Linux 2.6.11.2

[Greg KH]

On Fri, Mar 11, 2005 at 11:19:28AM -0800, Chris Wright wrote:
> * Matt Mackall (mpm@selenic.com) wrote:
> > Or do you want to do it the same way you do for every other branch? I
> > don't want to special-case it in my code and I don't think users want
> > to special-case it in their brains. Have separate interdiffs on the
> > side, please, and then people can choose, but do it the standard way.
> > 
> > Dear ${SUCKER}s, can we have a decision on this? My ketchup tool is
> > broken for 2.6.11.2 and I don't want to cut a new release until a firm
> > decision is made. Obviously I have a strong preference for all 2.6.x.y
> > diffs being against 2.6.x, it means that .y can be treated the same as
> > -rc, -bk, -mm, ... (and I already coded it that way when 2.6.8.1 came
> > out).
> 
> I agree with having the patch be against .x, with x.y -> x.y+1 interdiffs
> available on the side.  Greg, any issue with that?

No, I agree with that, and will not be hard to do at all (the release
script already handles this just fine.)  

I've held off rediffing 2.6.11.2 so far, as I don't know where to put
the x.y+1 interdiffs?  kernel/v2.6/incr/ ?  Any thoughts?

thanks,

greg k-h

Re: Linux 2.6.11.2

[Bill Davidsen]

On Fri, 11 Mar 2005, Greg KH wrote:

> On Fri, Mar 11, 2005 at 11:19:28AM -0800, Chris Wright wrote:
> > * Matt Mackall (mpm@selenic.com) wrote:
> > > Or do you want to do it the same way you do for every other branch? I
> > > don't want to special-case it in my code and I don't think users want
> > > to special-case it in their brains. Have separate interdiffs on the
> > > side, please, and then people can choose, but do it the standard way.
> > > 
> > > Dear ${SUCKER}s, can we have a decision on this? My ketchup tool is
> > > broken for 2.6.11.2 and I don't want to cut a new release until a firm
> > > decision is made. Obviously I have a strong preference for all 2.6.x.y
> > > diffs being against 2.6.x, it means that .y can be treated the same as
> > > -rc, -bk, -mm, ... (and I already coded it that way when 2.6.8.1 came
> > > out).
> > 
> > I agree with having the patch be against .x, with x.y -> x.y+1 interdiffs
> > available on the side.  Greg, any issue with that?
> 
> No, I agree with that, and will not be hard to do at all (the release
> script already handles this just fine.)  
> 
> I've held off rediffing 2.6.11.2 so far, as I don't know where to put
> the x.y+1 interdiffs?  kernel/v2.6/incr/ ?  Any thoughts?

I guess incr is as good as any, I thought you would put the "against base" 
somewhere, having already decided to do incrementals. Hopefully you will
at least change the numbering on the patch file (no, not the version in
the Makefile), so patch 2.6.11.3i is againt 2.6.11.2, and 2.6.11.3 is
against 2.6.11. That way people can tell after the download which one they
have if they forget.

I didn't like the initial decision to go incremental, and I even less like
changing now, but it's the right thing to do. It's not like we have a big
investment in scripts or anything, and you're doing the work.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Linux 2.6.11.2

[Greg KH]

On Mon, Mar 14, 2005 at 12:10:19PM -0500, Bill Davidsen wrote:
> I didn't like the initial decision to go incremental, and I even less like
> changing now, but it's the right thing to do. It's not like we have a big
> investment in scripts or anything, and you're doing the work.

And it's already done, see the 2.6.11.3 release announcement :)

greg k-h

Re: Linux 2.6.11.2

[Bill Davidsen]

Matt Mackall wrote:

> In your world, do you want to do:
> 
> cp -rl linux-2.6.11 linux-2.6.11.5
> cd linux-2.6.11.5
> bzcat ../Patches/patch-2.6.11.1.bz2 | patch -p1
> bzcat ../Patches/patch-2.6.11.2.bz2 | patch -p1
> bzcat ../Patches/patch-2.6.11.3.bz2 | patch -p1
> bzcat ../Patches/patch-2.6.11.4.bz2 | patch -p1
> bzcat ../Patches/patch-2.6.11.5.bz2 | patch -p1
> 
> I suspect you might find that tedious, especially if only the last one
> addressed a bug that affected you.

Being lazy, I would do
   bzcat ../Patches/patch-2.6.11.*.bz | patch -p1
(or similar). But as I posted long ago when this discussion started it 
is desirable to have both.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Linux 2.6.11.2

[David Greaves]

Bill Davidsen wrote:

> Matt Mackall wrote:
>
>> In your world, do you want to do:
>>
>> cp -rl linux-2.6.11 linux-2.6.11.5
>> cd linux-2.6.11.5
>> bzcat ../Patches/patch-2.6.11.1.bz2 | patch -p1
>> bzcat ../Patches/patch-2.6.11.2.bz2 | patch -p1
>> bzcat ../Patches/patch-2.6.11.3.bz2 | patch -p1
>> bzcat ../Patches/patch-2.6.11.4.bz2 | patch -p1
>> bzcat ../Patches/patch-2.6.11.5.bz2 | patch -p1
>>
>> I suspect you might find that tedious, especially if only the last one
>> addressed a bug that affected you.
>
>
> Being lazy, I would do
> bzcat ../Patches/patch-2.6.11.*.bz | patch -p1
> (or similar). But as I posted long ago when this discussion started it 
> is desirable to have both.
>
being super lazy I'd type:
scripts/patch-kernel . ../Patches

nb it's currently broke as mentioned in another thread:
Re: [BUG] Re: [PATCH] scripts/patch-kernel: use EXTRAVERSION
being fixed though. It will (I assume!) embody whatever rules are needed 
to revoke patches to go from 2.6.11.5 to 2.6.12 (and since I think the 
new version has d/l facilities, that should assist in the case of a base 
kernel d/l of 2.6.11.3 for which no local patches exist to revert prior 
to patching to 2.6.12)

David

Re: Linux 2.6.11.2

[Andy Whitcroft]

> which is a patch against the 2.6.11.1 release.  If consensus arrives
> that this patch should be against the 2.6.11 tree, it will be done that
> way in the future.

It seems to me that we have V (delta?) and VI (delta incremental) for 
all the other kernel patch series.  So perhaps we could have both, the V 
being from 2.6.11 and the VI from 2.6.11.1.

-apw

Re: Linux 2.6.11.2

[Marcelo Tosatti]

Hi Greg,

The st/ide-tape/osst llseek changes havent been applied for what reason? 

And what about the rest of fixups which Andrew sent you? 

I suppose they didnt pass the -stable criteria. Can you share your thoughts 
with the rest of us?

On Wed, Mar 09, 2005 at 12:39:23AM -0800, Greg KH wrote:
> And to further test this whole -stable system, I've released 2.6.11.2.
> It contains one patch, which is already in the -bk tree, and came from
> the security team (hence the lack of the longer review cycle).
> 
> It's available now in the normal kernel.org places:
> 	kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
> which is a patch against the 2.6.11.1 release.  If consensus arrives
> that this patch should be against the 2.6.11 tree, it will be done that
> way in the future.
> 
> A detailed changelog can be found at:
>  	kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.11.2
> 
> A bitkeeper tree for the 2.6.11.y releases can be found at:
> 	bk://linux-release.bkbits.net/linux-2.6.11
> 
> The diffstat and short summary of the fixes are below.  
> 
> I'll also be replying to this message with a copy of the patch itself,
> as it is small enough to do so.
> 
> thanks,
>  
> greg k-h
> 
> -------
> 
> 
>  Makefile       |    2 +-
>  fs/eventpoll.c |    3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> 
> Summary of changes from v2.6.11.1 to v2.6.11.2
> ============================================
> 
> Greg Kroah-Hartman:
>   o Linux 2.6.11.2
> 
> Linus Torvalds:
>   o epoll: return proper error on overflow condition

Re: Linux 2.6.11.2

[Greg KH]

On Wed, Mar 09, 2005 at 11:03:59AM -0300, Marcelo Tosatti wrote:
> 
> Hi Greg,
> 
> The st/ide-tape/osst llseek changes havent been applied for what reason? 
> 
> And what about the rest of fixups which Andrew sent you? 
> 
> I suppose they didnt pass the -stable criteria. Can you share your thoughts 
> with the rest of us?

They are in the -stable queue, and should go our for review later today,
and will attempt to follow the proposed proceedure.

I didn't add them to .2 as that was released just due to the security
update.

thanks,

greg k-h

Re: Linux 2.6.11.2

[Bill Davidsen]

Greg KH wrote:
> And to further test this whole -stable system, I've released 2.6.11.2.
> It contains one patch, which is already in the -bk tree, and came from
> the security team (hence the lack of the longer review cycle).
> 
> It's available now in the normal kernel.org places:
> 	kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
> which is a patch against the 2.6.11.1 release.  If consensus arrives
> that this patch should be against the 2.6.11 tree, it will be done that
> way in the future.

I think you need both x.y.z=>x.y.z.N and x.y.z.N-1=>x.y.z.N patches. My 
systems which are following the -stable will just need the most recent, 
but doing x.y.z-1=>x.y.z.N gets really ugly for higher values of N.

It can be automated, it's just two (presumably tiny) patchsets per release.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Linux 2.6.11.2

[Matt Mackall]

On Wed, Mar 09, 2005 at 12:39:23AM -0800, Greg KH wrote:
> And to further test this whole -stable system, I've released 2.6.11.2.
> It contains one patch, which is already in the -bk tree, and came from
> the security team (hence the lack of the longer review cycle).
> 
> It's available now in the normal kernel.org places:
> 	kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
> which is a patch against the 2.6.11.1 release.

Argh! @*#$&!!&! 

> If consensus arrives
> that this patch should be against the 2.6.11 tree, it will be done that
> way in the future.

Consensus arrived back when 2.6.8.1 came out.

Please, folks, there are automated tools that "know" about kernel
release numbering and so on. Said tools broke with 2.6.11.1 because it
wasn't in the same place that 2.6.8.1 was and now this breaks with all
precedent by being an interdiff along a branch.

Fixing it in the future is too #*$%* late because you've now turned it
into a special case.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Linux 2.6.11.2

[Randy.Dunlap]

Matt Mackall wrote:
> On Wed, Mar 09, 2005 at 12:39:23AM -0800, Greg KH wrote:
> 
>>And to further test this whole -stable system, I've released 2.6.11.2.
>>It contains one patch, which is already in the -bk tree, and came from
>>the security team (hence the lack of the longer review cycle).
>>
>>It's available now in the normal kernel.org places:
>>	kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
>>which is a patch against the 2.6.11.1 release.
> 
> 
> Argh! @*#$&!!&! 

I have to Argh this also (with Matt).


>>If consensus arrives
>>that this patch should be against the 2.6.11 tree, it will be done that
>>way in the future.

It would be much easier on users/testers to have to apply
only one patch to base (2.6.11 e.g.) to get to 2.6.x.y
(2.6.11.3 e.g.).  One Patch File.  Not three.

> Consensus arrived back when 2.6.8.1 came out.
> 
> Please, folks, there are automated tools that "know" about kernel
> release numbering and so on. Said tools broke with 2.6.11.1 because it
> wasn't in the same place that 2.6.8.1 was and now this breaks with all
> precedent by being an interdiff along a branch.
> 
> Fixing it in the future is too #*$%* late because you've now turned it
> into a special case.


-- 
~Randy

Re: Linux 2.6.11.2

[Greg KH]

On Wed, Mar 09, 2005 at 01:06:31PM -0800, Matt Mackall wrote:
> On Wed, Mar 09, 2005 at 12:39:23AM -0800, Greg KH wrote:
> > And to further test this whole -stable system, I've released 2.6.11.2.
> > It contains one patch, which is already in the -bk tree, and came from
> > the security team (hence the lack of the longer review cycle).
> > 
> > It's available now in the normal kernel.org places:
> > 	kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
> > which is a patch against the 2.6.11.1 release.
> 
> Argh! @*#$&!!&! 
> 
> > If consensus arrives
> > that this patch should be against the 2.6.11 tree, it will be done that
> > way in the future.
> 
> Consensus arrived back when 2.6.8.1 came out.

It did?  So, what was it agreed to be?  Any pointers to that agreement?

> Please, folks, there are automated tools that "know" about kernel
> release numbering and so on. Said tools broke with 2.6.11.1 because it
> wasn't in the same place that 2.6.8.1 was and now this breaks with all
> precedent by being an interdiff along a branch.

2.6.11.1 is now in the proper place, sorry for any inconvience that
caused.  This happened yesterday.

> Fixing it in the future is too #*$%* late because you've now turned it
> into a special case.

No, I can always respin the patch, and re-release it if it's a problem.

thanks,

greg k-h

Re: Linux 2.6.11.2

[Matt Mackall]

On Wed, Mar 09, 2005 at 03:11:57PM -0800, Greg KH wrote:
> On Wed, Mar 09, 2005 at 01:06:31PM -0800, Matt Mackall wrote:
> > On Wed, Mar 09, 2005 at 12:39:23AM -0800, Greg KH wrote:
> > > And to further test this whole -stable system, I've released 2.6.11.2.
> > > It contains one patch, which is already in the -bk tree, and came from
> > > the security team (hence the lack of the longer review cycle).
> > > 
> > > It's available now in the normal kernel.org places:
> > > 	kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
> > > which is a patch against the 2.6.11.1 release.
> > 
> > Argh! @*#$&!!&! 
> > 
> > > If consensus arrives
> > > that this patch should be against the 2.6.11 tree, it will be done that
> > > way in the future.
> > 
> > Consensus arrived back when 2.6.8.1 came out.
> 
> It did?  So, what was it agreed to be?  Any pointers to that agreement?

Deltas against 2.6.x tarballs. The discussion was some large fraction
of the 2.6.8.1 announce thread. I think someone else mentioned it in
the recent renumbering thread, so I didn't feel the need to
pre-emptively whinge this time around..

> > Fixing it in the future is too #*$%* late because you've now turned it
> > into a special case.
> 
> No, I can always respin the patch, and re-release it if it's a problem.

That'd make things easier, yes.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Linux 2.6.11.2

[Gene Heskett]

On Wednesday 09 March 2005 18:11, Greg KH wrote:
>On Wed, Mar 09, 2005 at 01:06:31PM -0800, Matt Mackall wrote:
>> On Wed, Mar 09, 2005 at 12:39:23AM -0800, Greg KH wrote:
>> > And to further test this whole -stable system, I've released
>> > 2.6.11.2. It contains one patch, which is already in the -bk
>> > tree, and came from the security team (hence the lack of the
>> > longer review cycle).
>> >
>> > It's available now in the normal kernel.org places:
>> >  kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
>> > which is a patch against the 2.6.11.1 release.
>>
>> Argh! @*#$&!!&!
>>
>> > If consensus arrives
>> > that this patch should be against the 2.6.11 tree, it will be
>> > done that way in the future.
>>
>> Consensus arrived back when 2.6.8.1 came out.
>
>It did?  So, what was it agreed to be?  Any pointers to that
> agreement?
>
>> Please, folks, there are automated tools that "know" about kernel
>> release numbering and so on. Said tools broke with 2.6.11.1
>> because it wasn't in the same place that 2.6.8.1 was and now this
>> breaks with all precedent by being an interdiff along a branch.
>
>2.6.11.1 is now in the proper place, sorry for any inconvience that
>caused.  This happened yesterday.
>
>> Fixing it in the future is too #*$%* late because you've now
>> turned it into a special case.
>
>No, I can always respin the patch, and re-release it if it's a
> problem.

Somewhat Greg, it caught me out.  OTOH, once we know that .2 needs .1, 
we'll be ok.  And it does give a quick method for us frogs to define 
if one of them is a regression.  The only thing that should break if 
we leave one out of the squence is the EXTRAVERSION path in the 
Makefile & we can certainly fix that easily enough for testing.

Question?  Is it a given that these, if they don't have warts, will be 
in mainline 2.6.12?

>thanks,
>
>greg k-h
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: Linux 2.6.11.2

[Bill Davidsen]

Gene Heskett wrote:

> Somewhat Greg, it caught me out.  OTOH, once we know that .2 needs .1, 
> we'll be ok.  And it does give a quick method for us frogs to define 
> if one of them is a regression.  The only thing that should break if 
> we leave one out of the squence is the EXTRAVERSION path in the 
> Makefile & we can certainly fix that easily enough for testing.

2nd that, I'm so delighted to have -stable that I will happily accept 
patches of what ever type you find easiest to produce, in this case 
sequential incrementals. Just don't screw the process by changing it, we 
can cope! Anyone who can't figure out how to generate the single big 
diff against mainline shouldn't be patching kernels ;-)
> 
> Question?  Is it a given that these, if they don't have warts, will be 
> in mainline 2.6.12?

I think Linus noted his intention to grab the fixes he likes. That's not 
a determanent process by any means ;-)


-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Linux 2.6.11.2

[Gene Heskett]

On Friday 11 March 2005 14:23, Bill Davidsen wrote:
>Gene Heskett wrote:
>> Somewhat Greg, it caught me out.  OTOH, once we know that .2 needs
>> .1, we'll be ok.  And it does give a quick method for us frogs to
>> define if one of them is a regression.  The only thing that should
>> break if we leave one out of the squence is the EXTRAVERSION path
>> in the Makefile & we can certainly fix that easily enough for
>> testing.
>
>2nd that, I'm so delighted to have -stable that I will happily
> accept patches of what ever type you find easiest to produce, in
> this case sequential incrementals. Just don't screw the process by
> changing it, we can cope! Anyone who can't figure out how to
> generate the single big diff against mainline shouldn't be patching
> kernels ;-)

Humm, that might be a pretty high fence for me to jump there Bill.  
ATM, what I'm running is 11.2, with the bk-ieee1394.patch, and for my 
uses, it certainly seems to be bulletproof.  But then I'm not running 
a server with 30,000 clients either, this is your classic geeks 
desktop here, even if the geek is 70 years old.  Firewire Just 
Works(TM), usb seems to be back among the living and I'm a relatively 
happy camper.  Till the next patch comes out & I'll just *have* to 
try it...  :)

Heck, if the next .3 patch just was a relabeled bk-ieee1394.patch, I'd 
be in Hog Heaven.  And if the next patch after that made my 
pcHDTV-3000 card work out of the box,  I'd offer the patch maker a 
couple of his favorite libations.  Hows that for a good deal?  So 
far, thats a re-install after every reboot situation now because the 
replacement modules are built out of the tree.

>> Question?  Is it a given that these, if they don't have warts,
>> will be in mainline 2.6.12?
>
>I think Linus noted his intention to grab the fixes he likes. That's
> not a determanent process by any means ;-)

We've noted that previously.  OTOH, he has always managed to come up 
with perfectly valid objections to those not accepted if queried 
about the whynots.  I can't argue with that for a heartbeat since I 
don't and cannot come close to having an overall view in as much 
detail as he obviously keeps in his head.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: Linux 2.6.11.2

[Krzysztof Halasa]

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

Hi,

Another patch for 2.6.11.x: already in main tree, fixes kernel panic
on receive with WAN cards based on Hitachi SCA/SCA-II: N2, C101,
PCI200SYN.
Also a documentation change fixing user-panic can-t-find-required-software
failure (just the same patch as in mainline) :-)

Please apply, thanks.
-- 
Krzysztof Halasa

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: hdlc-skb-dev.patch --]
[-- Type: text/x-patch, Size: 2492 bytes --]

--- linux/drivers/net/wan/hd6457x.c	28 Oct 2004 06:16:08 -0000	1.15
+++ linux/drivers/net/wan/hd6457x.c	1 Mar 2005 00:58:08 -0000
@@ -315,7 +315,7 @@
 #endif
 	stats->rx_packets++;
 	stats->rx_bytes += skb->len;
-	skb->dev->last_rx = jiffies;
+	dev->last_rx = jiffies;
 	skb->protocol = hdlc_type_trans(skb, dev);
 	netif_rx(skb);
 }
--- linux/drivers/net/wan/Kconfig	15 Jan 2005 23:46:55 -0000	1.25
+++ linux/drivers/net/wan/Kconfig	1 Mar 2005 00:58:08 -0000
@@ -155,7 +155,8 @@
 	  Network) card supported by this driver and you are planning to
 	  connect the box to a WAN.
 
-	  You will need supporting software from <http://hq.pm.waw.pl/hdlc/>.
+	  You will need supporting software from
+	  <http://www.kernel.org/pub/linux/utils/net/hdlc/>.
 	  Generic HDLC driver currently supports raw HDLC, Cisco HDLC, Frame
 	  Relay, synchronous Point-to-Point Protocol (PPP) and X.25.
 
@@ -225,7 +226,7 @@
 	  Driver for PCI200SYN cards by Goramo sp. j.
 
 	  If you have such a card, say Y here and see
-	  <http://hq.pm.waw.pl/hdlc/>.
+	  <http://www.kernel.org/pub/linux/utils/net/hdlc/>.
 
 	  To compile this as a module, choose M here: the
 	  module will be called pci200syn.
@@ -239,7 +240,7 @@
 	  Driver for wanXL PCI cards by SBE Inc.
 
 	  If you have such a card, say Y here and see
-	  <http://hq.pm.waw.pl/hdlc/>.
+	  <http://www.kernel.org/pub/linux/utils/net/hdlc/>.
 
 	  To compile this as a module, choose M here: the
 	  module will be called wanxl.
@@ -292,7 +293,7 @@
 	  SDL Communications Inc.
 
 	  If you have such a card, say Y here and see
-	  <http://hq.pm.waw.pl/hdlc/>.
+	  <http://www.kernel.org/pub/linux/utils/net/hdlc/>.
 
 	  Note that N2csu and N2dds cards are not supported by this driver.
 
@@ -308,7 +309,7 @@
 	  Driver for C101 SuperSync ISA cards by Moxa Technologies Co., Ltd.
 
 	  If you have such a card, say Y here and see
-	  <http://hq.pm.waw.pl/pub/hdlc/>
+	  <http://www.kernel.org/pub/linux/utils/net/hdlc/>.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called c101.
--- linux/MAINTAINERS	26 Jan 2005 16:47:14 -0000	1.332
+++ linux/MAINTAINERS	1 Mar 2005 00:58:08 -0000
@@ -910,10 +910,10 @@
 W:	http://www.icp-vortex.com/
 S:	Supported
 
-GENERIC HDLC DRIVER, N2 AND C101 DRIVERS
+GENERIC HDLC DRIVER, N2, C101, PCI200SYN and WANXL DRIVERS
 P:	Krzysztof Halasa
 M:	khc@pm.waw.pl
-W:	http://hq.pm.waw.pl/hdlc/
+W:	http://www.kernel.org/pub/linux/utils/net/hdlc/
 S:	Maintained
 
 HAYES ESP SERIAL DRIVER

Re: Linux 2.6.11.2

[Chris Wright]

* Krzysztof Halasa (khc@pm.waw.pl) wrote:
> Another patch for 2.6.11.x: already in main tree, fixes kernel panic
> on receive with WAN cards based on Hitachi SCA/SCA-II: N2, C101,
> PCI200SYN.
> Also a documentation change fixing user-panic can-t-find-required-software
> failure (just the same patch as in mainline) :-)

We are not accepting documentation fixes.  Could you please send just
the panic fix to stable@kernel.org (cc lkml)?  And add Signed-off-by...

thanks,
-chris

Re: Linux 2.6.11.2

[Bill Davidsen]

Chris Wright wrote:
> * Krzysztof Halasa (khc@pm.waw.pl) wrote:
> 
>>Another patch for 2.6.11.x: already in main tree, fixes kernel panic
>>on receive with WAN cards based on Hitachi SCA/SCA-II: N2, C101,
>>PCI200SYN.
>>Also a documentation change fixing user-panic can-t-find-required-software
>>failure (just the same patch as in mainline) :-)
> 
> 
> We are not accepting documentation fixes.  Could you please send just
> the panic fix to stable@kernel.org (cc lkml)?  And add Signed-off-by...

I really think you should not have a hard and fast rule on doc, for the 
case where a fix also makes the mainline doc wrong and someone might do 
something destructive reading the mainline docs and using the fixed 
code. Drivers come to mind.

I am NOT saying this is such a case, I'm just against zero tolerance 
rules when I can see a reasonable case where they don't do what you want.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Linux 2.6.11.2

[Krzysztof Halasa]

Chris Wright <chrisw@osdl.org> writes:

> * Krzysztof Halasa (khc@pm.waw.pl) wrote:
>> Another patch for 2.6.11.x: already in main tree, fixes kernel panic
>> on receive with WAN cards based on Hitachi SCA/SCA-II: N2, C101,
>> PCI200SYN.
>> Also a documentation change fixing user-panic can-t-find-required-software
>> failure (just the same patch as in mainline) :-)
>
> We are not accepting documentation fixes.  Could you please send just
> the panic fix to stable@kernel.org (cc lkml)?  And add Signed-off-by...

Sure:

Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl>

--- linux/drivers/net/wan/hd6457x.c	28 Oct 2004 06:16:08 -0000	1.15
+++ linux/drivers/net/wan/hd6457x.c	1 Mar 2005 00:58:08 -0000
@@ -315,7 +315,7 @@
 #endif
 	stats->rx_packets++;
 	stats->rx_bytes += skb->len;
-	skb->dev->last_rx = jiffies;
+	dev->last_rx = jiffies;
 	skb->protocol = hdlc_type_trans(skb, dev);
 	netif_rx(skb);
 }

-- 
Krzysztof Halasa

Re: Linux 2.6.11.2

[Chris Wright]

* Krzysztof Halasa (khc@pm.waw.pl) wrote:
> Chris Wright <chrisw@osdl.org> writes:
> 
> > * Krzysztof Halasa (khc@pm.waw.pl) wrote:
> >> Another patch for 2.6.11.x: already in main tree, fixes kernel panic
> >> on receive with WAN cards based on Hitachi SCA/SCA-II: N2, C101,
> >> PCI200SYN.
> >> Also a documentation change fixing user-panic can-t-find-required-software
> >> failure (just the same patch as in mainline) :-)
> >
> > We are not accepting documentation fixes.  Could you please send just
> > the panic fix to stable@kernel.org (cc lkml)?  And add Signed-off-by...
> 
> Sure:

Thanks, added to queue.
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: Linux 2.6.11.2

[Bodo Eggert]

Bill Davidsen <davidsen@tmr.com> wrote:

> I think you need both x.y.z=>x.y.z.N and x.y.z.N-1=>x.y.z.N patches. My
> systems which are following the -stable will just need the most recent,
> but doing x.y.z-1=>x.y.z.N gets really ugly for higher values of N.

bzcat ../patch-2.6.nn.[0-9].*|patch -p1

Re: Linux 2.6.11.2

[Matt Mackall]

On Thu, Mar 10, 2005 at 02:46:29AM +0100, Bodo Eggert wrote:
> Bill Davidsen <davidsen@tmr.com> wrote:
> 
> > I think you need both x.y.z=>x.y.z.N and x.y.z.N-1=>x.y.z.N patches. My
> > systems which are following the -stable will just need the most recent,
> > but doing x.y.z-1=>x.y.z.N gets really ugly for higher values of N.
> 
> bzcat ../patch-2.6.nn.[0-9].*|patch -p1

You left out the steps where you fetch them and verify their signatures.

-- 
Mathematics is the supreme nostalgia of our time.