![[LWN Logo]](http://old.lwn.net/images/lcorner.png)
![[LWN.net]](http://old.lwn.net/images/kernel.png)
|
|
|
 Sections: Main page Security Kernel Distributions Development Commerce Linux in the news Announcements Back page All in one big page See also: last week's Kernel page. |
Kernel developmentThe current development kernel release is 2.3.34, which came out (without announcement) on December 21. It contains some documentation updates, i2c and bttv driver work, lots of ide-tape changes, and major USB updates. Perhaps the most significant change to go in, however, is the large file support. In other words, the 2GB filesize limit is about to become a thing of the past. 2GB files may seem large, but this limit does actually create problems for a number of enterprise and scientific applications. Its elimination will be one of the strong points of 2.4. Sparc64 support is being merged into 2.3.35, currently available as a prepatch. This architecture should be working as of the next release, but 32-bit Sparc is in poor shape. Dave Miller says "It is hoped that sparc32 can be in working order by mid January but no promises." This might be an area where suitably skilled kernel hackers could help out a lot. What else needs to go in before 2.4? The number of requests is large, of course, and a lot of them are not going to happen. One endangered request which has picked up a lot of support, however, is 32-bit UIDs. Without the larger user ID numbers, networks with large numbers of users will find themselves in trouble - and perhaps looking at other operating systems. Even Linus has said that he wants to find a way to get 32-bit UID support in, if possible. Given the list of people supporting it, this enhancement will probably slip in somehow. Note that this change should not cause problems for applications - the C library has been treating user IDs as 32-bit values for some time. When will 2.4.0 come out? The folks at Tummy.com have announced another "when will the kernel come out?" pool - this one for 2.4. Last time around, the winner pegged the release time for 2.2.0 to within about 45 minutes. Let's not be so sloppy this time, OK? There will be a fabulous prize for the winner, though they have not figured out what it is yet... The current stable release remains 2.2.13, unchanged since October. Alan Cox has had a 2.2.14 prepatch (currently 2.2.14pre16) ready for some time, except that there is a persistent IDE problem that refuses to go away. Some users report a "buffer list corrupted" error, followed by any of a number of unpleasant happenings. 2.2.13 does not have this problem, it was introduced later. Clearly, 2.2.14 can not go out in this shape; if the problem resists for too long the kernel developers may revert to the 2.2.13 IDE code just to get something out. PCMCIA confusion. Where are the current PCMCIA drivers? This question, according to PCMCIA developer David Hinds, is "more complicated than it should be." The PCMCIA code has been integrated into the 2.3 kernel series, sort of. That process is still incomplete. Meanwhile, David has been applying fixes and updates to his standalone version of the drivers, since that is the version still in almost universal use. David has been trying to keep Linus up to date, but Linus has evidently started reworking some of the 2.3 PCMCIA code on his own. There is now, thus, a fork in the Linux PCMCIA implementation. David is working on fixing things up, but the situation is a bit of a mess for the time being. Hopefully this will get straightened out before 2.4 comes out. Threads confusion. A long thread started when Rasterman put a note on his news/diary page stating that he couldn't use Linux threads because all threads run in a single processor (even on SMP systems) and thus provide no performance increase. In fact, that is not the case. Linux does try to keep threads together on a single processor because there are performance benefits to doing so. But this processor affinity is weaker than the attractive force of an idle CPU. If multiple threads want to work simultaneously, and a CPU is idle, threads will move over. However, sharing the same memory context across multiple CPUs has performance problems of its own. For truly high performance on multiprocessor systems, it is probably better to create a shared memory mapping and create multiple processes with fork(). Then each processor can run with its own memory context, and things will go faster. User-mode kernel 0.2-2.3.31. Version 0.2-2.3.31 of the user-mode kernel port has been announced. This project has ported the Linux kernel to itself - it runs as a set of processes under another Linux kernel. As such, it's suitable for people who want to play with the kernel safely. Should the Intel processor serial number be available under Linux? Current kernels simply disable the serial number feature, seeing it as a privacy problem with no redeeming features. Some have said, however, that this approach is a bit heavy-handed, that it is better to make the serial number available - even if as an option which defaults to "off." It looks like the Pentium III patches will provide that option, but not everybody is happy. Some see it as the classic foot in the door; once the serial number is an option, somebody will put out an application that requires it, and soon everybody will need to enable it. The end result probably depends on the distributions - if they enable the serial number by default, applications may use it. Other patches and updates released this week include:
Section Editor: Jon Corbet |
December 23, 1999
| |
Copyright © 1999
Eklektix, Inc., all rights reserved
Next: Distributions