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