Linux-2.1.23 and administratrivia...

Linus Torvalds (torvalds@ev5.linux.S.xgw.FI)
Sun, 26 Jan 1997 20:13:46 +0200 (EET)

Hi all,
just a quick announcement of 2.1.23 on the normal ftp-sites: this kernel
contains several interesting patches:

- SMP cleanup: moving the kernel locks from low-level assembly into the C
level (where we can now start to make it a lot mroe efficient and
scalable). David Miller.

- Sparc updates. David & co.

- poll() system call. This one was required by Digital UNIX
compatibility, and as just about everybody else (except native
Linux/x86) including iBCS2 had a poll() emulation on top of select() I
decided to do it _correctly_. In 2.1.23 the native internal interface
is actually closer to "poll()", and select() is implemented on top of
that interface.

The poll() stuff (along with some other things) make Linux able to run
Digital UNIX 4.0 shared libs (or at least "netscape"), so if anybody has
had problems with the Digital UNIX binary compatibility on alphas you
might want to check it out with this kernel instead.

The SMP code isn't efficient _yet_, so don't expect to see a large jump in
scalability at this point. It's just a huge conceptual step on the way to
real scalability. And _definitely_ worth checking out for stability,
because the patches are non-trivial.

The sparc update means that the default kernel should be more-or-less in
sync with David Miller. Pretty much total integration.

Oh, over to other things. I just learnt that there have been lots of
patches on the kernel mailing lists, and people have wondered why they
haven't been applied. The simple answer is that I haven't been reading the
mailing lists for the last month or two, due to the new baby and my
thesis. The noise ratio was simply too bad for it to make much sense.

Please do continue to use the kernel mailing list for patches - but use it
more as a "please test this out before I submit this to Linus" medium. If
you have real patches that you _really_ think should go in the standard
kernel, you should send them to me directly (or alternatively to the
people that maintain that particular subsystem - I am not necessarily
always the best person to send patches to).

Final note: it is likely that our move to the US starts at the end of next
week. That's when the computers are packed and take the boat abroad. As a
result, I probably won't have access to computers at home, and while I
certainly intend to continue to maintain the kernel (through the
university), I'll have even less time for secondary concerns. Bug-reports
and valid patches will always be wellcome, but I might not react much to
anything else..

Sorry for the inconvencience, I can only say that this should be
temporary until we get settled down in the US..