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