Re: Linux 2.5.75

Re: Linux 2.5.75

[Andi Kleen]

Linus Torvalds <torvalds@osdl.org> writes:
> 
> Also, the only real point of a stable release is for distribution makers.
> That pretty much cuts the list of "needs to be supported" down to x86,
> ia64, x86-64 and possibly sparc/alpha.

No ppc, ppc64, s390?

Current bad issues for x86-64: 

- IDE Taskfile IO when enabled corrupts file systems on AMD8111
(on others too?).  This is the worst because there is no fix available.
I would propose to completely disable taskfile in Kconfig 
until the issue is resolved.

- Reiserfs zeroes every second 4K block in any write >4K on 64bit systems
(patch is in -mm*). Hopefully the patch can be merged before 2.6-pre.

and 

- doesn't compile (trivial fixes are already sent) 

-Andi

Re: Linux 2.5.75

[Linus Torvalds]

On 11 Jul 2003, Andi Kleen wrote:
>
> Linus Torvalds <torvalds@osdl.org> writes:
> > 
> > Also, the only real point of a stable release is for distribution makers.
> > That pretty much cuts the list of "needs to be supported" down to x86,
> > ia64, x86-64 and possibly sparc/alpha.
> 
> No ppc, ppc64, s390?

Do we have distributions that intend to make releases using those? I
suspect not, but hey, don't get me wrong: I'd love to see them working
out-of-the-box.

It's purely a matter of priorities. The only architecture that really 
_has_ to be stable is x86. Others are determined largely by whether they 
get their own testing done, and companies and individuals being willing to 
put the resources down.

			Linus

Re: Linux 2.5.75

[Paul Mackerras]

Linus Torvalds writes:

> On 11 Jul 2003, Andi Kleen wrote:
> >
> > Linus Torvalds <torvalds@osdl.org> writes:
> > > 
> > > Also, the only real point of a stable release is for distribution makers.
> > > That pretty much cuts the list of "needs to be supported" down to x86,
> > > ia64, x86-64 and possibly sparc/alpha.
> > 
> > No ppc, ppc64, s390?
> 
> Do we have distributions that intend to make releases using those? I
> suspect not, but hey, don't get me wrong: I'd love to see them working
> out-of-the-box.

SuSE has a ppc64 version of their enterprise server edition and I
think they include ppc32 kernels too.  Terrasoft does a distribution
aimed at powermac users.  Mandrake and Gentoo have ppc versions of
their distributions.  And of course there is Debian/PPC, which is what
I use.  I think ppc and ppc64 have well and truly eclipsed alpha and
sparc, in terms of the size of the market for distributions, by now.

In fact ppc and ppc64 are in pretty good shape in your tree as far as
the desktop and server machines are concerned.

Paul.

Re: Linux 2.5.75

[Christoph Hellwig]

On Thu, Jul 10, 2003 at 05:12:43PM -0700, Linus Torvalds wrote:
> Do we have distributions that intend to make releases using those? I
> suspect not, but hey, don't get me wrong: I'd love to see them working
> out-of-the-box.

RH AS and SLES support s390 and ppc64.  OTOH their trees are
patched to death so who cares :)

ppc32 is pretty important as lots of kernel developers love mac
hardware.  (Writing this from an ibook..)

Re: Linux 2.5.75

[Lars Marowsky-Bree]

On 2003-07-11T09:42:28,
   Christoph Hellwig <hch@infradead.org> said:

> > Do we have distributions that intend to make releases using those? I
> > suspect not, but hey, don't get me wrong: I'd love to see them working
> > out-of-the-box.
> RH AS and SLES support s390 and ppc64.  OTOH their trees are
> patched to death so who cares :)

We'd like to avoid that nightmare for 2.6 though, so we definetely
care.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
SuSE Labs - Research & Development, SuSE Linux AG
  
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
  -- Capt. Edward A. Murphy            -- Louis Pasteur

Re: Linux 2.5.75

[Christoph Hellwig]

On Fri, Jul 11, 2003 at 12:27:28PM +0200, Lars Marowsky-Bree wrote:
> We'd like to avoid that nightmare for 2.6 though, so we definetely
> care.

I don't know who "we" is, but SuSE/RH managment certainly doesn't
act like that by ACKed every bloody feature request from big blue
and friends..

Re: Linux 2.5.75

[Linus Torvalds]

On Fri, 11 Jul 2003, Lars Marowsky-Bree wrote:
> 
> We'd like to avoid that nightmare for 2.6 though, so we definetely
> care.

Hey, all the better. However, in that case I'd strongly suggest up the
management chain that people be aware of the fact that if they want 2.6.x
to be stable on anything but x86, it will need testing. Both internally
and externally. By doing things like running all the internal machines on 
a pre-2.6 kernel.

The same is true of x86 too, but there at least there will be test 
coverage even without vendor support. Vendors making their own internal 
distributions with pre-2.6 kernels will help on x86 too, of course. Hint 
hint.

(Late 2.3.x got much better coverage through things like this, so I'm not 
all that pessimistic. But people need to be aware of the issue).

		Linus

Re: Linux 2.5.75

[Arjan van de Ven]

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

On Fri, 2003-07-11 at 18:52, Linus Torvalds wrote:
\
> The same is true of x86 too, but there at least there will be test 
> coverage even without vendor support. Vendors making their own internal 
> distributions with pre-2.6 kernels will help on x86 too, of course. Hint 
> hint.


fwiw there are rpms of 2.5.75 that fit in Red Hat Linux 9 (plus updated
modutils, initscripts and mkinitrd from rawhide) on
http://people.redhat.com/arjanv/2.5
for people to play with.

(the files in this location will gets updated regularly)


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux 2.5.75

[Horst von Brand]

Arjan van de Ven <arjanv@redhat.com> said:

[...]

> fwiw there are rpms of 2.5.75 that fit in Red Hat Linux 9 (plus updated
> modutils, initscripts and mkinitrd from rawhide) on
> http://people.redhat.com/arjanv/2.5
> for people to play with.

Where are the non-kernel files? A kernel RPM on itself is not enough... and
for me at least ((semi-)regular bk-kernel tester) the least useful.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Linux 2.5.75

[Jeff Garzik]

Horst von Brand wrote:
> Arjan van de Ven <arjanv@redhat.com> said:
> 
> [...]
> 
> 
>>fwiw there are rpms of 2.5.75 that fit in Red Hat Linux 9 (plus updated
>>modutils, initscripts and mkinitrd from rawhide) on
>>http://people.redhat.com/arjanv/2.5
>>for people to play with.
> 
> 
> Where are the non-kernel files? A kernel RPM on itself is not enough... and
> for me at least ((semi-)regular bk-kernel tester) the least useful.


rawhide, like arjan said :)

Pick your favorite rawhide mirror.

	Jeff

Re: Linux 2.5.75

[Arnd Bergmann]

Linus Torvalds wrote:

>> 
>> No ppc, ppc64, s390?
> 
> Do we have distributions that intend to make releases using those? I
> suspect not, but hey, don't get me wrong: I'd love to see them working
> out-of-the-box.

At the moment, the s390 port is fully merged and functional (~30 known bugs,
more to be found) in the your tree, something that has never been the
case in 2.2 or 2.4.

I expect to see an official debian kernel for s390 2.6.early without any
architecture specific patches. The commercial distributions are likely
to remain some more time on 2.4.{19,21}, actually there are probably more
people still running 2.4.7 than 2.4.19 on s390...

        Arnd <><

Re: Linux 2.5.75

[Horst von Brand]

Russell King <rmk@arm.linux.org.uk> said:

[...]

> The major problem is that embedded developers only care about what
> works for them and what they can provide to their customers.  Once
> that's done, they don't have any interest in cleaning stuff up nor
> feeding obvious bug fixes back up.

I think this is rather uncivilized behaviour. Somebody called the work
invested in the general infrastructure or just donating money "watering the
garden". If they don't do that, they have no right to wonder later why it
dried up.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

RE: Linux 2.5.75

[Oliver Pitzeier]

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

Linus Torvalds wrote:
> Ok. This is it. We (Andrew and me) are going to start a 
> "pre-2.6" series, where getting patches in is going to be a 
> lot harder. This is the last 2.5.x kernel, so take note.

[ ... ]

Thanks a lot to all 'extreme'-kernel-developers and especially to Linus (as ever) and Andrew!

I just compiled 2.5.75 on my old Alpha (AS1000A/333, Noritake). It compiled without problems! And it started up without problems (some warnings, but nothing the can't be fixed with 'vi /etc/*'). :-)

So thanks a lot, you did a GREAT job! I hope to see 2.6 (or even better 3.0) soon on that machine.

I can only recommend 2.5 on Alpha. It was (believe it or not) a performance boost on this machine!

Best regards,
 Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (MingW32)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj8O29sACgkQEyZKIOgU3Si1ggCgh3QE8+IucC5NBpC/OaUDN+sP
U3sAnRLfssfUXlrhXdUcDRECfRbXd1KX
=Yyky
-----END PGP SIGNATURE-----

Re: Linux 2.5.75

[Benjamin Herrenschmidt]

On Thu, 2003-07-10 at 23:14, Linus Torvalds wrote:
> Ok. This is it. We (Andrew and me) are going to start a "pre-2.6" series,
> where getting patches in is going to be a lot harder. This is the last
> 2.5.x kernel, so take note.
> 
> The probably most notable thing here is the anticipatory scheduler,
> which has been in -mm for a long time, and was the major piece that
> hadn't been merged. 
> 
> Some architecture updates: cris has been updated for 2.5, ia64 and arm26 
> updates etc.  And various random (smallish) things.

Hi Linus !

I'm quite concerned about Power Management. Patrick haven't yet merged
the new implementation which changes the driver-side semantics to
something sane and your above mail seem to imply this is now too late.

While I agree these should have been merged a lot earlier, I'm also
annoyed by the fact that the existing save_state/suspend semantics
are just plain broken...

What do you plan on this regard ? Patrick, do you still need to hold
your patch until OLS ? They should get in now, that won't prevent
you from doing your paper ;)

Ben.

Re: Linux 2.5.75

[Wade]

Diego Calleja García wrote:

>El 10 Jul 2003 16:40:29 -0700 Robert Love <rml@tech9.net> escribió:
>
>  
>
>>I do not see it as a _huge_ problem, because we are just worrying about
>>corner cases now. Worst case we can turn off the interactivity estimator
>>- which is both the root of the improvement and the problems - and be
>>back to where we are in 2.4.
>>    
>>
>
>It used to work fine in the past; now as Felipe said, it's a PITA. Con's
>patch helps but it's not even near than what it used to be. My make -j 25
>without any skip is now -j3 with Con's patch and some mp3 skips. Perhaps
>i should start testing when it stopped "working" (i always save the kernel
>images)
>  
>
Please share this information if you find it :-) I would like a nice 
desktop kernel again too.

>Diego Calleja
>
>  
>

Re: Linux 2.5.75

[Diego Calleja García]

El 10 Jul 2003 16:40:29 -0700 Robert Love <rml@tech9.net> escribió:

> I do not see it as a _huge_ problem, because we are just worrying about
> corner cases now. Worst case we can turn off the interactivity estimator
> - which is both the root of the improvement and the problems - and be
> back to where we are in 2.4.

It used to work fine in the past; now as Felipe said, it's a PITA. Con's
patch helps but it's not even near than what it used to be. My make -j 25
without any skip is now -j3 with Con's patch and some mp3 skips. Perhaps
i should start testing when it stopped "working" (i always save the kernel
images)


Diego Calleja

Re: Linux 2.5.75

[Davide Libenzi]

On Thu, 10 Jul 2003, Linus Torvalds wrote:

> > Sometime ago, I made down a combo patch and, sincerely, it's the one I'm
> > using the most for my desktop boxes as it's the one that gets better
> > response times and interactive feeling. For my server boxes, neither my
> > combo patch, neither Con or stock do feel good when the system is under
> > heavy load. It suffers from starvation. Simply doing a "tar jxvf" makes
> > logging into the system a PITA.
>
> And this one is almost certainly not a process scheduler issue, but an IO
> scheduler one. 2.5.75 may help that a bit - anticipatory IO scheduling
> from the -mm tree, and a much simpler (and in my tests, noticeably faster
> and more robust) executable mmap prefetcher.
>
> But as with process scheduling, I don't believe in "perfect". It will just
> have to be "good enough for a lot of people".

Indeed. Yesterday while I was doing the SOFTRR hack I had after a quite
long time the opportunity to test the current scheduler interactivity. To
me it looks very good. My usual `make -j 40 bzImage` let my system
completely usable. If all this noise was for the tar thingy maybe we are
responsible to not have well read the thread to stop it soon.



- Davide

Re: Linux 2.5.75

[Robert Love]

On Thu, 2003-07-10 at 16:30, Felipe Alfaro Solana wrote:

> I'm worried about the current status of the 2.5 kernel scheduler.

I am sure Linus and Andrew will continue to take patches to tune the
scheduler, as long as they are clearly tuning issues.

I do not see it as a _huge_ problem, because we are just worrying about
corner cases now. Worst case we can turn off the interactivity estimator
- which is both the root of the improvement and the problems - and be
back to where we are in 2.4.

	Robert Love

Re: Linux 2.5.75

[Linus Torvalds]

On 11 Jul 2003, Felipe Alfaro Solana wrote:
> 
> Is there any expected or planned timeframe to finalize the pre-2.6
> series and end up with a stable 2.6.0 kernel?

It's a bit hard to plan, since it depends on just how well the pre-series 
ends up working for people. There are now people starting to use the 
current 2.5.x kernels for production use, and indicators look pretty good 
in general, but who can tell? 

So if I were to guess at a couple of months, then that's still just a 
guess.

> I'm worried about the current status of the 2.5 kernel scheduler. I know
> that Con is working hard to nail down all the problems that some people
> like me are having. I don't still feel comfortable with it, and although
> Con patches are several orders of magnitude better than stock scheduler,
> there are minor problems.

Quite frankly, I worry a lot more about device drivers etc than I do about 
the scheduler.

We'll never have "The Perfect Scheduler" (tm), since I don't think such a 
thing exists, but more importantly, I could live even with the current 
one, and I'm sure Con's will be better without having any huge stability 
issues.

> Sometime ago, I made down a combo patch and, sincerely, it's the one I'm
> using the most for my desktop boxes as it's the one that gets better
> response times and interactive feeling. For my server boxes, neither my
> combo patch, neither Con or stock do feel good when the system is under
> heavy load. It suffers from starvation. Simply doing a "tar jxvf" makes
> logging into the system a PITA.

And this one is almost certainly not a process scheduler issue, but an IO
scheduler one. 2.5.75 may help that a bit - anticipatory IO scheduling
from the -mm tree, and a much simpler (and in my tests, noticeably faster
and more robust) executable mmap prefetcher.

But as with process scheduling, I don't believe in "perfect". It will just 
have to be "good enough for a lot of people". 

			Linus

Re: Linux 2.5.75

[Felipe Alfaro Solana]

On Thu, 2003-07-10 at 23:14, Linus Torvalds wrote:
> Ok. This is it. We (Andrew and me) are going to start a "pre-2.6" series,
> where getting patches in is going to be a lot harder. This is the last
> 2.5.x kernel, so take note.

Is there any expected or planned timeframe to finalize the pre-2.6
series and end up with a stable 2.6.0 kernel?

I'm worried about the current status of the 2.5 kernel scheduler. I know
that Con is working hard to nail down all the problems that some people
like me are having. I don't still feel comfortable with it, and although
Con patches are several orders of magnitude better than stock scheduler,
there are minor problems.

Sometime ago, I made down a combo patch and, sincerely, it's the one I'm
using the most for my desktop boxes as it's the one that gets better
response times and interactive feeling. For my server boxes, neither my
combo patch, neither Con or stock do feel good when the system is under
heavy load. It suffers from starvation. Simply doing a "tar jxvf" makes
logging into the system a PITA.

Just my 2 cents.

Re: Linux 2.5.75

[Linus Torvalds]

On Fri, 11 Jul 2003, Russell King wrote:
> 
> Absolutely no surprise.  In any case, the long development cycle isn't
> what ARM stuff needs.

Well, nothing really _wants_ a long development cycle. I suspect any 
particular feature taken on its own always wants the shortest possible 
development cycle, and that what ends up happening is just that there are 
a lot of interdepencies and just plain "different" development-cycles.

Which is not a bad thing per se, and pretty clearly is unavoidable. So 
I'm not complaining. It's just a fact of life.

I think that the best way to "solve" the problem is to partially ignore 
it, and I don't think it's a bad thing that we have many different trees, 
and some of them are less strongly coupled to others - exactly to handle 
the inevitable case of release cycle lag.

For example, I absolutely detest the BSD "world" model, which actually 
makes these problems bigger by tying different projects together into one 
tree. I think it's much more important to try to have as much freedom as 
possible, including very much having separate timetables and development 
environments.

> Hasn't ever, I'm afraid.  I can't think of any stock kernel which has
> been usable, let alone been compilable for ARM.  Which, IMO, is a pretty
> sorry statement to make.

You see that as a sorry statement, but I don't think it's a failure. Why 
_should_ one tree have to try to make everybody happy? We want to try to 
make it easier to keep the couplings in place by striving for portable 
infrastructure etc, but we would only be hampered by a philosophy that 
says "everything has to work in tree X", since that just means that you 
can't afford to break things.

I'd much rather keep the freedom to break stuff, and have many separate
trees that break _different_ things, and let them all co-exist in a 
friendly rivalry.

And my tree is just one tree in that forest.

So it's not a bug - it's a FEATURE!

			Linus

Re: Linux 2.5.75

[Russell King]

On Thu, Jul 10, 2003 at 03:26:09PM -0700, Linus Torvalds wrote:
> On Thu, 10 Jul 2003, Russell King wrote:
> > 
> > Well, only two words from me.  Oh Shit.
> 
> Hey, this is already much later than it should have been, so it's not as
> if this is a huge surprise.

Absolutely no surprise.  In any case, the long development cycle isn't
what ARM stuff needs.

For example, during 2.3, people only started serious merging with myself
of the StrongARM SoC code towards the end of 2.3 when it became important
to them for 2.4.  That caused the serial layer rewrite around 2.4.2 time
and later spawned the cpufreq project, both of which has been maintained
ever since.  Now that StrongARM SoC has been end of life'd by Intel, most
of the work which went into 2.5 is wasted because probably no one will
ever use it.

A fine example of this was what happened with the touchscreen stuff
(thank god we got the input layer in 2.5.)

I see the same thing happening to the Intel PXA (Xscale stuff.)
Virtually the whole of the ARM community is working on 2.4 for Xscale
because that's the current stable kernel.  They're not interested in 2.6
until 2.6 actually comes out.  At this point, everyone will want their
drivers to work on that kernel.  Of course, 2.8 will be too late.

And then yours truely then ends up with loads of crap patches and we
start the process again.

The major problem is that embedded developers only care about what
works for them and what they can provide to their customers.  Once
that's done, they don't have any interest in cleaning stuff up nor
feeding obvious bug fixes back up.

> > The 2.5.70 ARM patch currently looks like this:
> 
> We can sort it out later. Obviously, clearly arm-specific patches (ie
> stuff in arch/arm and include/asm-arm) I wouldn't mind per se, but I'd
> rather hold back on even those just to make the patches and the changlogs
> not be mixed up with the "main bugfixes".

I've still got to sort out the module space and /proc/kcore - we allocate
the module space between TASK_SIZE and PAGE_OFFSET, which needs vmalloc
to be aware that entries on the vmlist may cover two allocatable areas.
Maybe this has changed, I haven't had time to look into this.  This is
probably the main reason why stock 2.5 (since Rusty's module changes
went in, recent) has never built for ARM.

I don't think the kclist stuff really fits this for me - it doesn't
allow me to do allocations off it, and I don't want yet another
list for modules.  I guess I'm going to stick with my current approach
of having two memory spaces in the vmlist.  (see patch).

> We've never had a first stable release that has all architectures
> up-to-date, and I'm not planning on changing that for 2.6.x. This is _not_
> the time to try to make my tree build on arm (or other architectures
> either), considering that my tree hasn't been the main ARM tree for a long 
> time.

Hasn't ever, I'm afraid.  I can't think of any stock kernel which has
been usable, let alone been compilable for ARM.  Which, IMO, is a pretty
sorry statement to make.


--- orig/mm/vmalloc.c	Tue May 27 10:05:48 2003
+++ linux/mm/vmalloc.c	Tue May 27 10:14:45 2003
@@ -178,21 +178,11 @@
 	return err;
 }
 
-
-/**
- *	get_vm_area  -  reserve a contingous kernel virtual area
- *
- *	@size:		size of the area
- *	@flags:		%VM_IOREMAP for I/O mappings or VM_ALLOC
- *
- *	Search an area of @size in the kernel virtual mapping area,
- *	and reserved it for out purposes.  Returns the area descriptor
- *	on success or %NULL on failure.
- */
-struct vm_struct *get_vm_area(unsigned long size, unsigned long flags)
+struct vm_struct *__get_vm_area(unsigned long size, unsigned long flags,
+				unsigned long start, unsigned long end)
 {
 	struct vm_struct **p, *tmp, *area;
-	unsigned long addr = VMALLOC_START;
+	unsigned long addr = start;
 
 	area = kmalloc(sizeof(*area), GFP_KERNEL);
 	if (unlikely(!area))
@@ -209,12 +199,14 @@
 
 	write_lock(&vmlist_lock);
 	for (p = &vmlist; (tmp = *p) ;p = &tmp->next) {
+		if ((unsigned long)tmp->addr < addr)
+			continue;
 		if ((size + addr) < addr)
 			goto out;
 		if (size + addr <= (unsigned long)tmp->addr)
 			goto found;
 		addr = tmp->size + (unsigned long)tmp->addr;
-		if (addr > VMALLOC_END-size)
+		if (addr > end - size)
 			goto out;
 	}
 
@@ -239,6 +231,21 @@
 }
 
 /**
+ *	get_vm_area  -  reserve a contingous kernel virtual area
+ *
+ *	@size:		size of the area
+ *	@flags:		%VM_IOREMAP for I/O mappings or VM_ALLOC
+ *
+ *	Search an area of @size in the kernel virtual mapping area,
+ *	and reserved it for out purposes.  Returns the area descriptor
+ *	on success or %NULL on failure.
+ */
+struct vm_struct *get_vm_area(unsigned long size, unsigned long flags)
+{
+	return __get_vm_area(size, flags, VMALLOC_START, VMALLOC_END);
+}
+
+/**
  *	remove_vm_area  -  find and remove a contingous kernel virtual area
  *
  *	@addr:		base address


-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Linux 2.5.75

[Linus Torvalds]

On Thu, 10 Jul 2003, Russell King wrote:
> 
> Well, only two words from me.  Oh Shit.

Hey, this is already much later than it should have been, so it's not as
if this is a huge surprise.

> The 2.5.70 ARM patch currently looks like this:

We can sort it out later. Obviously, clearly arm-specific patches (ie
stuff in arch/arm and include/asm-arm) I wouldn't mind per se, but I'd
rather hold back on even those just to make the patches and the changlogs
not be mixed up with the "main bugfixes".

We've never had a first stable release that has all architectures
up-to-date, and I'm not planning on changing that for 2.6.x. This is _not_
the time to try to make my tree build on arm (or other architectures
either), considering that my tree hasn't been the main ARM tree for a long 
time.

> Frustrated such an understatement.

To be blunt, which part of "we want to release 2.6.x this year" came as a
surprise to you? I

That means that I'm not willing to hold stuff up any more. Stuff that 
hasn't followed the development tree doesn't magically just "get fixed". 

Also, the only real point of a stable release is for distribution makers.
That pretty much cuts the list of "needs to be supported" down to x86,
ia64, x86-64 and possibly sparc/alpha.

So everything else is a bonus, but can equally well just play catch-up
later. Embedded people tend to want to stay back anyway, which is 
obviously why they don't follow the development tree in the first place. 

			Linus

Re: Linux 2.5.75

[Russell King]

On Thu, Jul 10, 2003 at 02:14:15PM -0700, Linus Torvalds wrote:
> Ok. This is it. We (Andrew and me) are going to start a "pre-2.6" series,
> where getting patches in is going to be a lot harder. This is the last
> 2.5.x kernel, so take note.

Well, only two words from me.  Oh Shit.

The 2.5.70 ARM patch currently looks like this:

 343 files changed, 45388 insertions(+), 7341 deletions(-)

and I don't see that this will be reducing in size now that 2.6 is around
the corner.

I _know_ ARM stuff doesn't build and hasn't built in Linus' tree for a
fair time now - there are some generic changes to support ARM modules
needed in vmalloc.c which I just haven't had the time to sort out, and
there's still the issue of whether /proc/kcore actually works or not,
and now I see that the time stuff needs re-working for multiple ARM
platforms yet again.  (yes, all the other architectures got updated,
except for ARM.)

Maybe I should just forget even attempting to merge upstream, like most
of the ARM community doesn't.

Frustrated such an understatement.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Linux 2.5.75

[Linus Torvalds]

Ok. This is it. We (Andrew and me) are going to start a "pre-2.6" series,
where getting patches in is going to be a lot harder. This is the last
2.5.x kernel, so take note.

The probably most notable thing here is the anticipatory scheduler,
which has been in -mm for a long time, and was the major piece that
hadn't been merged. 

Some architecture updates: cris has been updated for 2.5, ia64 and arm26 
updates etc.  And various random (smallish) things.

		Linus

-----

Summary of changes from v2.5.74 to v2.5.75
============================================

Adam Belay:
  o [PNP] Handle Disabled Resources Properly
  o [PNP] Allow resource auto config to assign disabled resources
  o [PNP] Fix manual resource setting API

Alex Williamson:
  o ia64: turn off ALLOW_IOV_BYPASS

Alexey Kuznetsov:
  o [TCP]: Delete obsolete comment

Andrew Morton:
  o move_vma() make_pages_present() fix
  o page unmapping debug
  o NUMA memory reporting fix
  o ramfs: use rgeneric_file_llseek
  o inode_change_ok(): remove lock_kernel()
  o nommu vmtruncate: remove lock_kernel()
  o procfs: remove some unneeded lock_kernel()s
  o remove lock_kernel() from file_ops.flush()
  o block_llseek(): remove lock_kernel()
  o Make CONFIG_TC35815 depend on CONFIG_TOSHIBA_JMR3927
  o Report detached thread exit to the debugger
  o timer renaming and cleanups
  o fix lost_tick detector for speedstep
  o fix lost-tick compensation corner-case
  o cleanup and generalise lowmem_page_address
  o Security hook for vm_enough_memory
  o ext2: inode allocation race fix
  o fix double mmdrop() on exec path
  o ext3: fix journal_release_buffer() race
  o Set limits on CONFIG_LOG_BUF_SHIFT
  o Fix cciss hang
  o e100 use-after-free fix
  o PCI domain scanning fix
  o ipc semaphore optimization
  o bring back the batch_requests function
  o Create `kblockd' workqueue
  o elv_may_queue() API function
  o elevator completion API
  o anticipatory I/O scheduler
  o Use kblockd for running request queues
  o per queue nr_requests
  o blk_congestion_wait threshold cleanup
  o allow the IO scheduler to pass an allocation hint to
  o handle OOM in get_request_wait()
  o block batching fairness
  o generic io contexts
  o block request batching
  o get_io_context fixes
  o block allocation comments
  o after exec_mmap(), exec cannot fail
  o bootmem.c cleanups
  o epoll: microoptimisations
  o fix current->user->__count leak
  o MTD build fix for old gcc's
  o fix rfcomm oops
  o i2o_scsi build fix
  o Improve mmap readaround
  o use task_cpu() not ->thread_info->cpu in sched.c
  o misc fixes
  o breadahead() tweaks
  o proc_attr_lookup() fix
  o xattr: cleanups
  o xattr: blockdev inode selection fix
  o xattr: update-in-place optimisation
  o xattrr: preparation for fine-grained locking
  o xattr: fine-grained locking
  o Module autoloading for quota
  o display bootserver in /proc/net/pnp
  o BSD accounting speedup

Anton Blanchard:
  o enable device mapper in compat layer

Arun Sharma:
  o ia64: IA-32 support patch: msgsnd/msgrcv return value off by 4
  o ia64: IA-32 support patch: munmap should return EINVAL if size == 0
  o ia64: IA-32 support patch: mmap should return ENOMEM

Ben Collins:
  o [SPARC64]: Fix formatting and typos in boot Makefile
  o [SPARC64]: Enable KALLSYMS, use print_symbol()

Benjamin Herrenschmidt:
  o fix IDE init oops on PowerMac

Bernardo Innocenti:
  o Fix do_div() for all architectures
  o Fix problem introduced by do_div() patch

Bruno Ducrot:
  o powernow-k7 typo fix

Chad Talbott:
  o ia64: SN2 updates

Dagfinn Ilmari Mannsåker:
  o Allow modular DM

Dave Jones:
  o [AGPGART] SiS 755 support for AMD K8 GART
  o [CPUFREQ] Fix stupid inverted FID/VID bug
  o [CPUFREQ] update cpufreq docs to reflect newly merged architecture
    support From Dominik Brodowski
  o [AGPGART] Add AGP3 support for all VIA AGP3 chipsets
  o [AGPGART] Fill out bridge structure with pdev before querying agp
    version
  o [CPUFREQ] Misc cleanups
  o [CPUFREQ] kobj refcount fixes
  o [CPUFREQ] move cpufreq_restore(), and don't make it dependent on
    CONFIG_PM
  o [CPUFREQ] don't care about "rmmod -f". It's expected to break
    things
  o [CPUFREQ] More misc cleanups

Dave Kleikamp:
  o JFS: Possible trap/data loss when fixing directory index table
  o JFS: If unicode conversion fails, operation should fail
  o JFS: Make error return codes negative
  o JFS: add nointegrity mount option

David Mosberger:
  o ia64: A couple of additional fixes to sync with 2.5.73+
  o ia64: support arch_get_unmapped_area() cache
  o ia64: Remove UNW_DEBUG again.  Adding it was a mistake
  o ia64: Fix LOAD_OFFSET macro in kernel linker script.  Reported by
    Mika Penttil.
  o ia64: Sync up with 2.5.74+
  o Use ".incbin" for initramfs image build

David S. Miller:
  o [SPARC64]: Move raid xor into library assembler file
  o [SPARC64]: Kill all irq_cpustat_t except __softirq_pending
  o [SPARC64]: Use kstat_this_cpu where possible
  o [TCP]: Initialize socket route on move to established state
  o [TCP]: Eliminate spurious CWND restart on every new connection
  o [SUNHME]: Set RXMAX/TXMAX large enough to handle VLAN frames

Dmitry Torokhov:
  o [NET] Attach inner qdiscs to TBF

Eric Sandeen:
  o [XFS] add swsusp support to xfs daemons

Gary Hade:
  o ia64: fix for sys32_sysinfo bug

Greg Kroah-Hartman:
  o PCI: change WARN_ON(irqs_disabled()) to WARN_ON(in_interrupt()) to
    keep the fusion drivers happy
  o sysfs: change print() to pr_debug() to not annoy everyone
  o SYSFS: add module referencing to sysfs attribute files
  o sysfs: add sysfs_rename_dir() Based on a patch written by Dan Aloni
    <da-x@gmx.net>
  o kobject: add kobject_rename() Based on a patch written by Dan Aloni
    <da-x@gmx.net>
  o driver core: added class_device_rename() Based on a patch written
    by Dan Aloni <da-x@gmx.net>
  o driver core: add my copyright to class.c

Greg Ungerer:
  o selection of boot parameters at configure time for Motorola 5282
    targets
  o conditional ROMfs copy for Motorola M5307C3 board
  o force PAGE_SIZE to be an unsigned long
  o remove unused register from clobber list in down_trylock()
  o simplify access_ok() for all m68knommu targets
  o shared library support for MMUless binfmt_flat loader
  o flat loader H8/300 specific support abstracted
  o flat loader m68knommu specific support abstracted
  o flat loader v850 specific support abstracted
  o conditional ROMfs copy for Cleopatra/5307 board
  o .no .romvec section for DragonEngine/68328 target
  o define shared lib limits for flat loader
  o cleanup show_process_blocks() for non-mmu targets
  o define raw read/write for m68knommu io access
  o remove 68360 specific trap init call
  o 68328 DragenEngine configure updates
  o conditional ROMfs copy for SecureEdgeMP3/5307 board
  o DragenEngine interrupt handler to use irqreturn_t
  o conditional ROMfs copy for NETtel/5307 board
  o fix security_initcall in m68knommu linker script
  o clean module_exit in m68knommu serial drivers
  o fix return type of m68knommu timer handler to be irqreturn_t
  o fix interrupt handler passed as arg to return irqreturn_t
  o use irqreturn_t in ColdFire interrupt setup code

Herbert Xu:
  o [IPSEC] Add policy expiration
  o [IPSEC] Fix refcnt leak in xfrm_lookup

Hideaki Yoshifuji:
  o [IPV6] fix a mistake in ipv6_advmss() conversion
  o [NET] Fix oops with /proc/net/{raw,igmp,mfilter,
    raw6,igmp6,mfilter6,anycast,ip6_flowlabel}.
  o [NET] Send only unicast NSs in PROBE state
  o [IPV6] ignore on-link information without on-link flag set
  o [IPV6] remove unused variable
  o [IPV6] fix algorithm for updating lifetime
  o [ATM] Convert clip neigh table to C99 initializers
  o [IPV6] Fix BUG when appending destination options headers

Hirofumi Ogawa:
  o FAT maintainership

Ian Molton:
  o ARM26 architecture update

Ingo Molnar:
  o another timer overflow thing
  o Double unlock in BSD accounting speedup patch

James Morris:
  o [IPSEC]: Do not call request_module() under spinlock in
    xfrm_get_type()

Jason Lunz:
  o [NET] Fix refcounting of dev->promiscuity for af_packet

Jean-Luc Richier:
  o [IPV6] Fix ipv6_addr_prefix() for prefixlen != 0 (mod 8)

Jeff Garzik:
  o fix via irq routing Via irq routing has a funky PIRQD location.  I
    checked my datasheets and, yep, this is correct all the way back to
    via686a.
  o [netdrvr 8139too] fix debug printk

John Levon:
  o OProfile: __exit fixes
  o OProfile: needed fix to IO-APIC timer
  o OProfile: fix a comment

John Marvin:
  o ia64: don't let PTRACE_POKEDATA write the NaT bits of syscall args

John Stultz:
  o jiffies include fix This patch fixes a bad declaration of jiffies
    in timer_tsc.c and timer_cyclone.c, replacing it with the proper
    usage of jiffies.h.

Krzysztof Halasa:
  o C99 initializers in hdlc_generic.c

Linus Torvalds:
  o The sbp2 driver needs <linux/pci.h>, but didn't include it. It
    apparently used to work due to some random magic indirect include,
    but broke lately.
  o Add an asynchronous buffer read-ahead facility. Nobody uses it for
    now, but I needed it for some tuning tests, and it is potentially
    useful for others.
  o Re-organize "ext3_get_inode_loc()" and make it easier to follow by
    splitting it into two functions: one that calculates the position,
    and the other that actually reads the inode block off the disk.
  o Carl-Daniel Hailfinger suggest adding a paranoid incoming trigger
    as per the "bk help triggers" suggestion, so that we'll see any new
    triggers showing up in the tree.
  o Go back to defaulting to 6-byte commands for MODE SENSE, since some
    drivers seem to be unhappy about the 10-byte version. 
  o When forcing through a signal for some thread-synchronous event (ie
    SIGSEGV, SIGFPE etc that happens as a result of a trap as opposed
    to an external event), if the signal is blocked we will not invoce
    a signal handler, we will just kill the thread with the signal.
  o Simplify and speed up mmap read-around handling
  o Fix several broken macros to get the "private" field of a seq-file
    in the networking code.
  o Avoid deadlocking on thread shutdown after a vfork
  o Fix IDE initialization when we don't probe for interrupts
  o Make the gcc version checks use the preprocessor symbols
    consistently.
  o Update CREDITS file and other documentation about my new email
    address
  o Fix up the IDE irq disable to take into account some
  o Fix mailer-induced corruption in initramfs build rules

Lode Leroy:
  o [IPV4] display bootserver in /proc/net/pnp

Marc Zyngier:
  o EISA: core changes
  o EISA: Documentation update
  o EISA: More EISA ids
  o EISA: PA-RISC changes
  o EISA: PCI-EISA dma_mask
  o EISA: avoid unnecessary probing

Martin Diehl:
  o Missing IrDA stuff for 2.5.73-bk8: sir_dev

Martin Hicks:
  o ia64: fix register-backing store initialization for main thread

Matthew Wilcox:
  o PCI: Improve documentation Fix some grammar problems Add a note
    about Fast Back to Back support Change the slot_name recommendation
    to pci_name().
  o PCI: arch/i386/pci/direct.c can use __init, not __devinit
    pci_sanity_check() is only called from functions marked __init, so
    it can be __init too.
  o PCI: pci_find_bus needs a domain Give pci_find_bus a domain
    argument and move its declaration to <linux/pci.h>
  o PCI: Remove pci_bus_exists Convert all callers of pci_bus_exists()
    to call pci_find_bus() instead.
  o PCI: arch/i386/pci/irq.c should use pci_find_bus Use pci_find_bus
    rather than relying on the return value of pci_scan_bus.
  o PCI: arch/i386/pci/legacy.c: use raw_pci_ops Make
    pcibios_fixup_peer_bridges() use raw_pci_ops directly instead of
    faking pci_bus and pci_dev.
  o PCI config space in sysfs
  o Driver Core: fix firmware binary files Fixes the sysfs binary file
    bug.
  o ia64: Use generic pci_scan_bus()

Mikael Starvik:
  o CRIS architecture update for 2.5.74

Paul Fulghum:
  o synclink.c update
  o synclinkmp.c update
  o synclink_cs.c update

Paul Mackerras:
  o Compile fix and cleanup for macserial driver

Pavel Machek:
  o New maintainter for nbd
  o suspend SMP-kernel with one CPU
  o Fix thinko in acpi
  o Fix swsusp with PREEMPT

Randy Dunlap:
  o [IPV6] use correct mib struct
  o [NET] Add MODULE_LICENSE (GPL) to wanroutrer so that kernel is not
    tainted

Roger Luethi:
  o via-rhine 1.18-2.5: Fix Rhine-I regression

Russell King:
  o [SERIAL] Don't return -ERESTARTSYS if signals aren't pending

Rusty Russell:
  o Remove cpu arg from cpu_raise_irq
  o Per-cpu variable in mm/slab.c
  o Remove unused __syscall_count
  o Make ksoftirqd a normal per-cpu variable
  o Make kstat_this_cpu in terms of __get_cpu_var and use it
  o switch_mm and enter_lazy_tlb: remove cpu arg

Scott Feldman:
  o [e1000] request_irq() failure resulted in freeing twice
  o [e1000] fix VLAN support on PPC64
  o [e1000] missing Tx cleanup opportunities during intr handling
  o [e1000] alloc_etherdev failure didn't cleanup regions
  o [e1000] ethtool diag cleanup
  o [e1000] h/w workaround for mis-fused parts
  o [e1000] s/int/unsigned int/ for descriptor ring indexes
  o [e1000] misc cleanup

Stephen Hemminger:
  o Change OSDL address in CREDITS
  o [NET]: PPP handling fragmented skbuffs

Stephen Lord:
  o Remove unused xfs_syncd.c file
  o Cleanup xfs and pagebuf sysctl code, use posix initializers to
    avoid confusion in the future over which constants apply to which
    initializers.

Steve French:
  o Fix compiler warning
  o cifs xattr support part 1
  o Signing fixes (1-4)
  o Update cifs vfs information and readme
  o Fix statfs failure due to invalid value for ffree

Steven Cole:
  o update Documentation/Changes, scripts/ver_linux

Thomas Graf:
  o [NET]: Make {send,recv}msg return EMSGSIZE when msg_iovelen is too
    big, as per 1003.1

Tom Rini:
  o PPC32: Update the OpenPIC code
  o PPC32: Update the bootloader serial code to have stub functions
  o PPC32: Remove references to a removed file
  o PPC32: Minor KGDB updates
  o PPC32: Add a backend for standard (ns1655x) UARTs for debugers
  o PPC32: Update the Motorola Sandpoint support
  o PPC32: Fix CONFIG_NVRAM && !CONFIG_PPC_PMAC
  o Remove the Zynx 4500 platform code.  It was old and unmaintained
  o PPC32: Remove the MEN F1 platform code.  It was old and
    unmaintained

Trond Myklebust:
  o Add open intent information to the 'struct nameidata'
  o Pass 'nameidata' to ->create()
  o Pass 'nameidata' to ->permission()
  o Use the intents in 'nameidata' to improve NFS close-to-open
    consistency
  o make create() follow symlinks again

Ulrich Drepper:
  o wrong pid in siginfo_t
  o tgkill patch for safe inter-thread signals

Ville Nuorvala:
  o [IPV6] fix a dst leakage and clean-up in tcp_v6_connect()
  o [NET]: Fix tunnel device bugs added by alloc_netdev() changes
  o [IPV6]: Fix DST handling bug in ip6ip6_err()
  o [IPV6]: Convert ip6ip6 tunnel driver to alloc_netdev()