Messages in this thread |  | | Date | Sat, 2 Nov 1996 15:00:59 +0200 (EET) | From | Linus Torvalds <> | Subject | Re: Since so many people have asked me this |
| |
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
|  |