See also: last week's Kernel page.

Kernel development

Perhaps the biggest change in this prepatch, however, is the addition of IEEE 1394 ("firewire") support. The new driver is marked "experimental," of course, and may remain that way when 2.4 comes out. But, it is no longer true that Linux does not support firewire. More information on Linux IEEE 1394 development can be found on the project web page.

The current stable kernel release remains 2.2.14. The prepatch series for 2.2.15 continues; it is currently up to 2.2.15pre3.

The 2.4 kernel appears to be getting more distant. In theory kernel development is in a feature freeze, and Linus had said back in December that he wanted to get the pre-2.4 series going before the end of the year. 2.4.0 was supposed to happen in the first quarter of 2000.

Since then much has happened. The block (disk) device layer has been strongly reworked, to the point that the driver API has changed and both Alan Cox and Linus have said that the expanding scope of the work is making them nervous. The PCMCIA code has been thrashed, Linus and PCMCIA developer David Hinds are getting grumpy with each other, and a lot of things never have worked in that subsystem.

All of the work that is being done makes sense - but it is very late in the development cycle to be making fundamental changes. By the time all of the changes are completed and properly tested, it will be too late for a "Q1 2000" release. That particular time frame does not matter a whole lot, but this kernel does need to go out at some point.

Cryptographic code in the kernel is coming - maybe. The advantages of including code for secure authentication and communications in the kernel have been known for years - but regulation of such code in several countries has blocked its inclusion. Now that the U.S. has evidently decriminalized the export of open source crypto code, the last roadblock appears to have been removed. People are starting to talk about what to put in.

In particular, H. Peter Anvin is currently in the process of getting legal advice on the matter. If the lawyers say he can get away with it, the kernel.org site (and its mirror system) will begin to carry cryptographic code. Kernel.org, of course, is the home of the official kernel; once this site can carry cryptographic code, Linus seems inclined to start including it.

The issue is not entirely resolved, however. Of particular concern is that the new U.S. law allows the export of open-source crypto source, but not binaries. As a result, the Linux distributions (which are the source of almost everybody's kernels) are still in a bit of a bind. One obvious solution would be to package up the crypto code in source form, then compile it as part of the installation process. Such silliness is not that hard to arrange, but the real point is that traps still abound. A more secure Linux (and Internet) may now be possible, but it will have to be approached with care.

Now that we have 32-bit user ID values, how about 32-bit process ID's as well? Unix systems have limited PID values to 15 bits for a long time, but there is nothing magic about that size. Larger PIDs would allow for some nice things, starting with the ability to have a great many processes active on a single system. There is also a (very small) security advantage in having a large PID space, and thus avoiding the reuse of PID values. Finally, people working with clusters have wanted for a while to be able to make PIDs unique across an entire cluster; this could be accomplished by reserving part of the PID space for a host number.

Given the advantages of larger PIDs, why not go ahead and increase the size of the PID field while the user ID field is being changed? Interestingly, it has already been done. According to Linus, the size of a PID has not only been 32 bits since Linux 0.01, but Linux for some time actually used all of those bits as well. It was a bug in bash that caused Linus to drop back to only using 15 bits, but it has always been stored in a 32-bit space.

Thus, Linux could switch over to 32-bit PIDs tomorrow with very little pain. There's just a few things to be worked out. One is that SYSV IPC uses 16-bit PID values for a user-visible structure. Glibc as a whole uses 32-bit values, but the IPC interface would have to change in a way that would break existing programs (this change appears to already be in the works, at least at the kernel level). Then there is the issue of /proc, which could turn into a very large, crowded directory with that many PIDs active. And, finally, nobody has yet worked out how the wider space should really be used. Should the new bits just become more bits in the PID, or should some of them be set aside for some sort of host ID?

Until these questions are worked out, Linus plans to leave PID values as they are: 15-bit quantities in a 32-bit space.

Other patches and updates released this week include:

• Version 2.0 of the Netware file system has been announced by the Timpanogas Group. It is currently only available in binary form. Source is evidently forthcoming, but has been delayed due to some weirdness that is best read directly from the announcement.

• Jeremy Fitzhardinge announced a rework of the autofs automounter to support "tree mounts."

• Modutils 2.3.9 was announced by Keith Owens.

• Lennert Buytenhek has made available a complete rewrite of the ethernet bridging code.

• Mike Sullivan posted an IBM PCI token ring Lanstreamer driver.

• Mikhail Moreyra has posted a driver for Cirrus Logic CL-MD5620DT modems.

• Randy Dunlap posted a priority list for USB development up to the 2.4 kernel. There is a lot to do still...

Section Editor: Jonathan Corbet

For other kernel news, see: Kernel traffic Kernel Newsflash Kernel Trap Linux 2.5.x Porting help

Other resources: Kernel Source Reference L-K mailing list FAQ Linux-MM Linux Scalability Effort Kernel Newbies Linux Device Drivers

Next: Distributions