The feature freeze is coming [LWN.net]

As part of the 2.5.40 announcement, Linus reminded the world that the feature freeze is coming soon:

And a small reminder that we're now officially in the last month of features, and since I'm going to be away basically the last week of October, so I actually personally consider Oct 20th to be the drop-date, unless you've got a really good and scary costume.. So don't try to leave it to the last day.

Linus also let it be known that he's "perfectly happy with the kernel" and feels no need to deal with last-minute code submissions.

In fact, the list of outstanding features is getting smaller. A couple of big changes that are pending, and which could be disruptive, are:

Changing the sector_t type to 64 bits, allowing block devices to be larger than 2TB. One would think that 2TB would last for a while, even by the standards of modern disks, but large RAID arrays are already pushing that boundary. A patch (by Peter Chubb) is being prepared, but it's taking him a while; among other things, he points out that testing is a slow process because it takes a full day just to write 4TB to a device.
Turning dev_t into a 32-bit value. Increasing the number of devices has been on the list since long before the 2.5 series began, but the change has not yet been made. This is not a trivial change, since the major device number is still used to index into static arrays within the kernel. Drastically increasing the number of devices requires dealing with those arrays. Alexander Viro has a plan to that end, but a lot of work remains to be done.

Beyond that, quite a few other developments are pending, and they won't all get in. Some outstanding items include the completion of the Linux Security Module and asynchronous I/O merges, ext3 indexed directory support, Rusty Russell's new module loader, a new kernel configuration and build system, a whole pile of memory management work, etc.

What also remains to be seen is how serious Linus is about the feature freeze. Past kernel freezes have tended to be slushy at best. Some substantial work will have to be integrated after the freeze; it will be interesting to see what gets in as "stabilization" or "feature completion."

Then, there is the much-publicized debate over whether the next stable series should be 2.6 or 3.0. Linus started by saying that there was nothing all that revolutionary in this kernel, and that it should be called 2.6. Numerous other developers disagreed, however, and Linus appears to have relented. It seems likely that the next major stable kernel will be called Linux 3.0.

(Log in to post comments)

The feature freeze is coming

Posted Oct 3, 2002 15:30 UTC (Thu) by IkeTo (subscriber, #2122) [Link]

> in Linux changes in major number have always ment binary
> incompatability with previous versions.

Major version number change happened exactly once previously, so there is nothing wrong to define it in any way Linus wants. And, indeed even 2.0 -> 2.2 or 2.2 -> 2.4 requires some user-level incompatible API changes (especially when we talk about the /proc filesystem). On the other hand, the system call interface had been very stable (only addition, no major change in semantics) because everything becomes a new syscall rather than redefine an old one (you find a getuid for 16 bits UID and another for 32 bits one). "Major number changes means API (or even ABI) changes" works for applications, but not the kernel.

The feature freeze is coming

Posted Oct 3, 2002 17:39 UTC (Thu) by ksmathers (guest, #2353) [Link]

The change from 0.6 & 0.9 to 1.0 was also a major number change. The main problem with changing major revisions in my mind is that based on past history (Platypus to Penguin), a new major revision should also get a new kernel mascot. If we are to leave behind Tux what are we going to get to replace him.

The feature freeze is coming

Posted Oct 3, 2002 17:34 UTC (Thu) by iabervon (subscriber, #722) [Link]

I think a major version increment makes sense when there's been a substantial change in the functionality the system offers. While this doesn't necessarily change the API, it greatly changes the way programs should use the API; there could be a substantial difference in which system calls should be used for reasonable performance, which would then lead to source-level changes in how things are implemented, not for correct function but for acceptable performance.

These sorts of changes build up over time, and it doesn't make sense to only consider the incremental effect; after a while it becomes clear that there are major differences, even if you can't point to a time when they all happened (in fact, Linux should probably never have a release where everything changes at once, since that would be overly disruptive and very difficult to debug). The differences introduced in 2.5 don't seem that major, but there are many substantial differences since 2.0. When writing code for 2.5, you're likely to want to have many threads, to take advantage of SMP, to avoid large select/poll, and so forth. On 2.0, SMP wasn't really worth coding for, and select was the most efficient way to deal with multiple IO streams, since multiple processes for a single purpose were inefficient.

Furthermore, I think it is a good idea to have interfaces deprecated for an entire major version before they are removed. When you clean out the old APIs in bulk, you want a clear mark for when the APIs you're removing were deprecated. You don't want to remove all of the deprecated interfaces, including the ones you deprecated the day before and everybody is still using. If you include signalling your intention to remove interfaces as an API change (since people will hopefully change even code that currently works in response), it's probably time for a new major version.

The feature freeze is coming

Posted Oct 3, 2002 20:24 UTC (Thu) by tjc (subscriber, #137) [Link]

What do people here think? 2.6 or 3.0?

3.0

The left side of my brain says 2.6. Although the improvements are significant, they are still incremental. There's no technical reason to make concessions based on people's infatuation with round numbers.

On the other hand, 2.6 is just a number, like 3.0 or 3.1001 or 7.0. If Sun can jump Solaris from 2.6 to 7.0 in one release, I don't see why Linux can't do the same. I think a 3.0 release would get a lot more press than a 2.6 release. This in itself would seem to make 3.0 a good choice, give the lack of any significant drawbacks.

Perhaps from now on they should all be major number releases. :-)

The feature freeze is coming

Posted Oct 4, 2002 11:08 UTC (Fri) by bjn (guest, #2179) [Link]

Sun didn't jump Solaris from 2.6 to 7.0 -- look at "uname -a" to see that it still says 5.7 -- it was marketing that called it "7" (no .0 after it). SunOS 5.7 = Solaris 2.7 = "Solaris 7" on the box.

The feature freeze is coming

Posted Oct 4, 2002 14:52 UTC (Fri) by tjc (subscriber, #137) [Link]

look at "uname -a" to see that it still says 5.7

I no longer have access to Sun workstations, and I really don't miss them that much. :-)

-- it was marketing that called it "7"

Yep, that's my main point -- there's no really compelling technical reason for or against naming the next kernel 3.0, so they might as well call it 3.0 and surf in on a wave of free press.

The feature freeze is coming

Posted Oct 14, 2002 19:41 UTC (Mon) by tigerand (guest, #6150) [Link]

> People seem keen to jump to 3.0 but I can't see any major ABI changes that would support
> this change. Lets not join the distributions in the silly major version number inflation crisis.

I couldn't have said it better myself. Don't go to 3.0 unless there is a good reason, and, as many here have said, there isn't a good reason. Let's at least wait until we have an honest-to-goodness not-lame VFS layer before we go trumpeting some great new major number release. I think of 2.6 v. 2.4 the way I think of Windows 98 v. Windows 95: basically a bug fix release, with some major BS (bad stuff), that shouldn't have gone in anyway, cleaned up, and some major good sutff, that should have gone in in the first place, added. Some of which is being back-ported to 2.4 anyway. Yeah, there's some new stuff coming to 2.6, and it's all good, but not enough to be a 3.0. Let's get a real VFS, I'm tired of being embarrassed by that. Once we have that, we can truely put NT and Solaris to bed ~:^)