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.4.0-test7, which was released just before LWN went to "press." There is no official announcement, but Linus's summary of 2.4.0-test7-pre7 gives a mostly-complete list of what is in -test7. As would be expected, it consists mostly of bug fixes; there is also a fair amount of moving files around as part of the driver reorganization (see below). One thing that did go in after -pre7 was the TUN/TAP virtual network driver. The current stable kernel release is still 2.2.16. The latest 2.2.17 prepatch is 2.2.17pre19. This prepatch was put out on August 18 as the final one, but the official stable release has yet to happen as of this writing. vger.rutgers.edu is no more. As was reported last week, the system which has handled linux-kernel and many other mailing lists for years suffered a disk disaster and went off the net. David Miller had been planning to move the lists anyway (the folks at Rutgers were getting tired of them), so this failure was the obvious opportunity to finish the job. The lists made a brief stop at vger.redhat.com, but not everybody was happy with the use of a vendor-specific domain. So the lists moved again - at least virtually - to their permanent home at vger.kernel.org. Some effort went into scrubbing every mention of Red Hat from the list headers. So, to all appearances, linux-kernel is redhat-clean, but Red Hat is still hosting the list - and doing the community a favor in the process. If you were on any of the old vger lists, you should have gotten the note saying that you have to resubscribe to the new version. All of the lists are controlled by majordomo, so the usual subscription drill applies. Driver locations, code sharing and the 'curse of the gifted'. This week's linux-kernel fight started out as part of an ongoing effort to reorganize the device driver tree. This reorganization has created some new directories such as "media" for things like video drivers and "input" for joysticks and such. Many drivers have found new homes in this process, but Linus drew the line at a patch that moved many of the USB drivers into the "input" directory. Most Linux users, most likely, are not concerned with the details of the organization of the Linux kernel source tree. But the conversation took a more interesting turn when one person defended the change by saying that it would help to promote sharing of code between drivers. Linus answered back with a statement that code sharing is not all it has been cracked up to be, and that often it's better to just make a copy of something useful and modify it as needed. Unsurprisingly, quite a few people disagree with this assessment. But it's worth considering his point of view for a moment. Linus is essentially saying that overzealous attempts to share code lead to modules that have been stretched beyond what they can comfortably handle. The result is a great many special cases, situations that maintainers can not test, and bugs. Rather than deal with all that, why not just make a copy that is able to properly handle a specific situation? For what it's worth, Linus's comments are very general, but his examples all have to do with device drivers that try to support too wide a variety of hardware. There certainly are situations in that area where splitting code apart makes sense, especially when support of old, "legacy" hardware can be left behind in a relatively static driver. But the comments on code sharing in general have caused some concern among members of the linux-kernel list. In particular, Eric Raymond joined in with an interesting letter accusing Linus of suffering from the "curse of the gifted." In Eric's view, Linus resembles the talented high school student who need not study to do well, and, as a result, never learns how. Linus's programming talents are such that he has never had to adopt the tools and techniques that most programmers rely on: things like source code management systems, bug tracking and regression testing systems, and, yes, code sharing. The talented high school student in Eric's example falls apart at the University because the necessary study skills have never been developed. Eric fears that something similar could happen when the complexity of the Linux kernel reaches a point that it outstrips even Linus's talents. Will he, at that point, be able to fall back on the software engineering techniques that so many others depend on? If you accept Eric's "curse of the gifted" argument, it is an issue worth pondering. Other patches and updates released this week include:
Section Editor: Jonathan Corbet |
August 24, 2000
| ||