To: linux-kernel@vger.rutgers.edu
Subject: Life after 2.0...
From: Linus Torvalds <torvalds@cs.helsinki.fi>
Date: Mon, 10 Jun 1996 08:53:10 +0300 (EET DST)


This is a "policy" message, not a very technical one, and none of the things
here are really set in stone. This just contains some rough plans for the
immediate future, and you're free to discuss/flame etc, especially as I won't
be around for a while.

Anyway, the current plans for 2.0 itself:

 - I'll be leaving on Wednesday for Argentina, and I'll be away for
   roughly ten days. After that I'll probably be off for another week
   just taking a vacation in Finland.

   This is planned - I wanted to get 2.0 out before leaving, and I _want_
   there to be a pause in development while people try out 2.0.0. I hope
   there will be no major problems with the .0 release, and if there are
   I hope they can be discussed publicly (hopefully there will even be
   unofficial patches to take care of the worst).

   When I get back I will probably have enough pacthes to make a 2.0.1,
   as I already have a few cosmetic things (and one more driver).

 - I _hope_ that eventually when 2.0.x starts to calm down (may that be
   quickly), we can come to some agreement about a "2.0 group" of people
   that will continue to keep 2.0 up-to-date, so that it won't die off
   when most of the developers move to 2.1.  This group would take care
   of any new developments (not in the kernel itself, but things like new
   drivers that may need to be ported back to 2.0 if they turn out to be
   successful and people need them like the 2940 driver in the 1.2.x
   releases).

Plans for 2.1:

 - We'll have at _least_ a month before I'm even "opening" the 2.1
   development tree. Some developers will hate this, but I really want
   people to use 2.0 for a while, even developers. That way if there are
   problems, there won't be  two separate trees making bugfixing harder.

   There are obviously some projects that will continue to be developed
   (IPv6 and the other ports like sparc etc), but I ask that at least the
   IPv6 people don't make too much noise about themselves right now, so
   that we won't fork too early. I'll be integrating back any of your
   patches soon enough..

 - After opening up 2.1, I'll first start integrating back the stuff that
   I started rejecting for 2.0. This includes IPv6 and Sparc/m68k patches.
   That does _not_ mean that they'll all be in 2.1.0 - for my sanity I
   want to go reasonably slowly, and judging by 1.3.x it will probably be
   something like 2.1.15 until it has all been integrated back.

 - x86-specific things: I'll be getting rid of the "%fs" register for
   user-mode accesses. Instead, I'll make the kernel data segment cover
   the full 32-bit address space, and thus kernel code will really see
   that it's mapped at virtual address 0xC0000000. That will mean, among
   other things, that drivers can no longer assume that kernel virtual
   addresses are the same as physical addresses (but there will be a
   simple 1:1 mapping, and the functions to take care of it already exists
   and are used on the non-x86 platforms - it really isn't too painful).

   Getting rid of %fs allows us to do some things faster, and also allows
   us to share some code: "memcpy()" and "memcpy_touser()" will be the
   same function (but one word of warning: _conceptually_ you still have to
   use the "get_user()" etc functions, not direct pointer accesses. Other
   platforms may still have a special user mode segment or other special user
   mode addressing requirement. There is also a code movement issue wrt the
   non-atomicity of user mode accesses and gcc optimization).

 - the generic plans for 2.1 is just to make things faster, support more
   hardware, and do it cleanly. That includes PPC/ARM/etc support,
   improved SMP code etc etc. We certainly have things to do, no worry
   about it getting boring.

The over to other things - maintainers. It looks like Alan is slowly
disassociating himself from networking, to be concentrating on SMP and other
things (Linux/086, he's one sick puppy). We'll try to cope: most of the
networking subsystems have their own "sub"maintainers, so hopefully it won't
be too painful.

I'll probably end up maintaining the basics of networking, at least for a
while. I've been wanting to make some re-organizations anyway, like getting
rid of the "struct socket", and making the networking use inodes like
everything else does (it actually does already, except it hides it by hiding
the "struct socket" inside the inode, and this adds some unnecessary
complexity). This may be temporary, depending on whether some person shows up
who is able (and wants) to be in charge of networking. I certainly will NOT
be able to do some of the things Alan has done, simply because I don't know
the networking protocols as well as he does.

The SCSI layer is now mostly in the hands of Leonard Zubkoff (take a bow), if
only because I trust him and he seemed willing. Eric is still around, and
we'll pester him endlessly, but I hope he'll be busy doing shared libraries
for the alpha, because I really WANT them ;-). People have been discussing
SCSI changes for a while - the SCSI layer needs to be streamlined a bit and
made a lot easier to understand.

Anything I forgot?

                Linus