From: Linus Torvalds < torva...@cs.helsinki.fi>
Subject: Linux-2.1.6
Date: 1996/10/29
Message-ID: < Pine.LNX.3.91.961029181542.292A-100000@linux.cs.Helsinki.FI>#1/1
X-Deja-AN: 192943194
sender: owner-linux-ker...@vger.rutgers.edu
references: < w4od8y1pz30.fsf@deneb.cs.rose-hulman.edu>
content-type: TEXT/PLAIN; charset=US-ASCII
x-hdr-sender: torva...@cs.helsinki.fi
mime-version: 1.0
x-env-sender: owner-linux-kernel-outgo...@vger.rutgers.edu
newsgroups: linux.dev.kernel
Ok, I'm back, and I made a 2.1.6 release. I'll try to make a 2.0.24 release
later today, but quite frankly I had 1500+ emails to go through, and I want
to calm down a bit before making that release..
As usual, the patches and tar-files are available on
ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/v2.1/
ftp://ftp.cs.helsinki.fi/pub/Software/Linux/Kernel/v2.1/
2.1.6 does:
- changed some implementation details of the user access macros on x86: it
seems my old inline assembly wasn't really 100% stable. That might have
led to unexpected problems (incorrect copying of memory etc). The new code
also does a first version of constant-size optimizations.
- new sound driver. I haven't actually tested whether it even compiles, but
hey, it can't be worse than 2.1.5 ;)
- updated ISDN code. Some of the code has been updated by yours truly (the
readb/membase stuff for the TELES driver) without having access to the
hardware or even compiling it, but as you all know I never make mistaeks,
so it will obviously work on the first try. It _might_ even work on
alphas.
- math emulation should work again on 386's..
- SCC character driver rewritten to be a real network driver instead.
- getting rid of "segment.h" eventually..
- cdu31a should work with sound again
- aha2940 driver temporary disable to make it boot for some people
(please tell me if it still doesn't work for you)
- eata driver update
- and the big-ping patch, of course..
For obvious reasons (see about email above), I've been kind of busy and
haven't had time to check all the changes I made on an alpha yet. Testers
appreciated.
Also, if you have sent me patches and don't see them in 2.1.6, you can
more-or-less assume that I don't have them pending, but am hoping to have
them re-sent in the near future (but don't all flood me immediately, I'd
rather avoid having to go through 50 patches in one day).
Linus
From: Linus Torvalds <torva...@cs.helsinki.fi>
Subject: Linux-2.0.24
Date: 1996/10/30
Message-ID: <Pine.LNX.3.91.961030052322.21147C-100000@linux.cs.Helsinki.FI>#1/1
X-Deja-AN: 193083473
sender: owner-linux-ker...@vger.rutgers.edu
references: <Pine.LNX.3.91.961029181542.292A-100000@linux.cs.Helsinki.FI>
content-type: TEXT/PLAIN; charset=US-ASCII
x-hdr-sender: torva...@cs.helsinki.fi
mime-version: 1.0
x-env-sender: owner-linux-kernel-outgo...@vger.rutgers.edu
newsgroups: linux.dev.kernel
Uhh, the time is now 05:23 AM, and I finally got the 2.0.24 release together.
Could people please test this out, so that I could at least feel that I
haven't been up this late (early) for nothing? I'm going to bed,
Linus
From: Linus Torvalds <torva...@cs.helsinki.fi>
Subject: Linux-2.1.7
Date: 1996/11/01
Message-ID: <Pine.LNX.3.91.961101163734.2932D-100000@linux.cs.Helsinki.FI>#1/1
X-Deja-AN: 193698991
sender: owner-linux-ker...@vger.rutgers.edu
references: <Pine.LNX.3.91.961029181542.292A-100000@linux.cs.Helsinki.FI>
content-type: TEXT/PLAIN; charset=ISO-8859-1
x-hdr-sender: torva...@cs.helsinki.fi
mime-version: 1.0
x-env-sender: owner-linux-kernel-outgo...@vger.rutgers.edu
newsgroups: linux.dev.kernel
Ok, 2.1.7 is out there in ftp-land, and has the new clever exception handling
implementation done by Richard Henderson for both x86 and alpha (I think the
idea was originally Ingo Molnars, but I could be mistaken, and Richard
certainly took it to new heights of elegance). Anyway, the new stuff uses
some clever linker tricks to essentially do zero-cost exception handling
rather than having to waste precious instructions to update the per-task
exception structure. Very nifty indeed.
The interface is still exactly the same, only some low-level architecture-
specific implementation details changed. It's all so clever that it's scary.
People interested in low-level scary stuff should take a look at the
uaccess.h files for x86 or alpha, and be ready to spend some time just
figuring out what it all does ;)
Anyway, the new exceptions do have a down-side: the exception tables do not
currently get exported from kernel loadable modules. This is not something
fundamentally hard: it's just something that needs to be handled by the
insmod &co people, and which hasn't been done yet. Anybody who feels he can
be useful in making insmod talk to the kernel about the exception tables
(Björn? Jacques?), please contact Richard <r...@tamu.edu> about this.
Note that the lack of exception data in modules does _not_ mean that modules
don't work. It only means that modules can't handle user space address
exceptions, and thus can't recover gracefully from EFAULT errors. As such you
can still load and use the modules (assuming you have the other 2.1.x fixes
for insmod module loading), but I'd suggest against it on any system with
untrusted users that you expect to do nasty things just for fun.
Apart from the new clever exceptions, the other changes in 2.1.7 are:
- baycom driver is a real network driver instead of a strange character
driver.
- soundmodem driver. You don't want to know what perversions people are
up to ;) (If you _do_ want to know, read the docs)
- various drivers which had boo-boo's with the new exception code fixed
up (ie ftape/md/cdrom/eql should work again)
- isdn silly problems should be fixed
- scc driver update
- tulip driver multicast lists
- aha1740 should work again (virtual/physical address probs on x86,
funnily it worked on alpha)
- quota unmount bug should be fixed in 2.1.x too
Anyway, I finally think the exception stuff is starting to be stable (apart
from the issues on module loading), and I think I'll try to start integrating
some of the other patches in the next few weeks. So expect to start seeing
ipv6/PPC/Sparc/m68k/ARM etc patches any week now (and my apologies to the
developers of those things for being slow to react - you're all in my queue
of things to handle, I've just been slow to get everything else cleared up).
Linus
From: a...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Since so many people have asked me this
Date: 1996/11/02
Message-ID: <m0vJeti-0005KgC@lightning.swansea.linux.org.uk>#1/1
X-Deja-AN: 193948754
sender: owner-linux-ker...@vger.rutgers.edu
x-hdr-sender: a...@lxorguk.ukuu.org.uk
x-env-sender: owner-linux-kernel-outgo...@vger.rutgers.edu
newsgroups: linux.dev.kernel
Whats in 2.0.23ac#2 thats not in 2.0.24
1. SMP irq forwarding, this gives BIG performance/latency improvements
with Linux/SMP, but its not exactly a bug fix.
2. Linus version of the socket change uses int not __u32. I'll submit
that as a patch again to use __u32 for the benefit of the folks trying to
get the Linux stack running on a certain 16bit OS
3. Several bugs that Linus and others fixed between 2.0.23/2.0.24
Thats it.. so unless you want to play with some of the fun SMP stuff, use
2.0.24. My next patch will be 2.0.24ac#1 and will just be whatever patches
I send to Linus for 2.0.25, and the SMP improvements for those who need
good SMP interrupt latency etc.
Alan
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
From: Linus Torvalds <torva...@cs.helsinki.fi>
Subject: Re: Since so many people have asked me this
Date: 1996/11/02
Message-ID: <Pine.LNX.3.91.961102144109.794A-100000@linux.cs.Helsinki.FI>#1/1
X-Deja-AN: 193953738
sender: owner-linux-ker...@vger.rutgers.edu
references: <m0vJeti-0005KgC@lightning.swansea.linux.org.uk>
content-type: TEXT/PLAIN; charset=US-ASCII
x-hdr-sender: torva...@cs.helsinki.fi
mime-version: 1.0
x-env-sender: owner-linux-kernel-outgo...@vger.rutgers.edu
newsgroups: linux.dev.kernel
On Sat, 2 Nov 1996, Alan Cox wrote:
>
> Whats in 2.0.23ac#2 thats not in 2.0.24
>
> 1. SMP irq forwarding, this gives BIG performance/latency improvements
> with Linux/SMP, but its not exactly a bug fix.
I was worried about the implications of this on the low-level code the
changes to .S files that I was too lazy to test because I don't run 2.0.x any
more). It's potentially still a subject for 2.0.x, but Alan's patches also
reverted some of the entry.S code to an older version for a reason that I
couldn't see (I _suspect_ the reason was just a version skew between us, but
I didn't want to play around with the code when I couldn't test it on SMP
anyway, so I chickened out and just didn't use that part of the patch at
all).
[ "Chicken, chicken, Linus is a chicken, kvaa kvaa kvaa.." ]
> 2. Linus version of the socket change uses int not __u32. I'll submit
> that as a patch again to use __u32 for the benefit of the folks trying to
> get the Linux stack running on a certain 16bit OS
The reason I didn't like that one was that I don't like using __u32 unless
you really want _exactly_ 32 bits. So I'll happily use __u32 for sequence
numbers, on-disk block numbers, IPv4 addresses etc, but I don't like it when
the only reason is that you really want to have "enough" bits rather than
exactly 32 bits.
On the other hand, "long" is not a good idea either, because using 64 bits on
the machines I use for it is way overkill. The day we need more than 4GB
counters for socket memory allocation I think I'll retire ;)
Alan, I suspect we need a new type for Linux/8086. Something that isn't
hardware-specific like "u32", and would allow strange architectures to use 36
bits or whatever they want to. Suggestions?
(No, I don't seriously consider porting to an architecture that doesn't
support "u32" easily, my argument is not technical in that sense. I just
argue for a way of thinking: think of the "u32" mentality as a necessary evil
that should be avoided whenever possible and used only when absolutely
necessary).
Maybe it's just me that's unnecessarily anal about "u32". It's a perfectly
good size, it's just the implications of it that I don't like.
> 3. Several bugs that Linus and others fixed between 2.0.23/2.0.24
The most important of these is probably the selection wait-queue stuff. It
will never bite you if you use only X and not gpm/selection at all, but if
you're an avid console user and switch between consoles a lot and use
selection it can be deadly.
The bug is hard to see - it results in random memory corruption and the
panics are not generally even close to where the bug actually is. And the
corruption doesn't seem to be all that usual, as the bug seems to be
reasonably hard to trigger in the first place. But it's at least potentially
very serious.
Oh, .24 also added a bug (that was also in 23ac): the tulip driver multicast
address enabling code has a wrong constant (0x08000 should be 0x08000000)
resulting in potential strange problems with tulip hardware. Damn, I'll have
to make a .25 for that (and for the SCSI host ordering change which is less
lethal but can be rather confusing).
Linus
From: Tuomas Heino <tbit...@xgw.fi>
Subject: Re: Linux-2.0.27 and 2.1.14
Date: 1996/12/01
Message-ID: <Pine.LNX.3.91.961201203817.3188A-100000@xgw15.pal.xgw.fi>#1/1
X-Deja-AN: 201741848
sender: owner-linux-ker...@vger.rutgers.edu
references: <Pine.LNX.3.95.961201202320.29211A-100000@ev5.linux.S.xgw.FI>
content-type: TEXT/PLAIN; charset=US-ASCII
x-hdr-sender: tbit...@xgw.fi
mime-version: 1.0
x-env-sender: owner-linux-kernel-outgo...@vger.rutgers.edu
newsgroups: linux.dev.kernel
When compiling 2.1.14 I got this:
make[2]: Entering directory `/usr/src/linux-2.1.14/net/core'
make all_targets
make[3]: Entering directory `/usr/src/linux-2.1.14/net/core'
make[3]: *** No rule to make target `net_alias.h', needed by
`net_alias.o'. Stop.
make[3]: Leaving directory `/usr/src/linux-2.1.14/net/core'
make[2]: *** [first_rule] Error 2
From: Linus Torvalds <torva...@cs.helsinki.fi>
Subject: Re: Linux-2.0.27 and 2.1.14
Date: 1996/12/01
Message-ID: <Pine.LNX.3.95.961201205307.304A-100000@linux.cs.Helsinki.FI>#1/1
X-Deja-AN: 201752617
sender: owner-linux-ker...@vger.rutgers.edu
references: <Pine.LNX.3.91.961201203817.3188A-100000@xgw15.pal.xgw.fi>
content-type: TEXT/PLAIN; charset=US-ASCII
x-hdr-sender: torva...@cs.helsinki.fi
mime-version: 1.0
x-env-sender: owner-linux-kernel-outgo...@vger.rutgers.edu
newsgroups: linux.dev.kernel
On Sun, 1 Dec 1996, Tuomas Heino wrote:
>
> When compiling 2.1.14 I got this:
> make[2]: Entering directory `/usr/src/linux-2.1.14/net/core'
> make all_targets
> make[3]: Entering directory `/usr/src/linux-2.1.14/net/core'
> make[3]: *** No rule to make target `net_alias.h', needed by
> `net_alias.o'. Stop.
> make[3]: Leaving directory `/usr/src/linux-2.1.14/net/core'
> make[2]: *** [first_rule] Error 2
Oops. The new and improved "mkdep.c" is no longer very forgiving about
header files that do not exist, and the net_alias.c file has a few
#include's that are used for user-level debugging but do not exist in the
kernel.
Fix: remove the stuff that is within the ALIAS_USER_LAND_DEBUG in
net_alias.c, redo the dependencies and go..
(alternatively you can put the comment /*nodep*/ btween the #-mark and the
"include", which forces mkdep to ignore the dependency)
Linus
|