To: linux-kernel@vger.rutgers.edu Subject: Life after 2.0... From: Linus Torvalds 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