![[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 Letters All in one big page See also: last week's Kernel page. |
Kernel developmentThe current development kernel release is 2.5.7. Linus is on vacation, so no 2.5.8 prepatches have been released. Dave Jones released 2.5.7-dj1 on March 21. "Resync, add compile fixes, simmer for 30 mins on low heat. Add random pending patches to taste. Still untested beyond 'it compiles', handle with care." Here is Guillaume Boissiere's 2.5 status summary for March 27. The current stable kernel release is 2.4.18; the current 2.4.19 prepatch from Marcelo remains 2.4.19-pre4; released on March 20. Alan Cox's latest prepatch is 2.4.19-pre4-ac2. It includes a great many fixes and a lot of USB updates, but there have been no major changes since the new IDE code went in last week. When close() goes bad. The close() system call is defined with the usual sort of return value: zero on success, nonzero otherwise. Most programmers do not look too closely at the return value from close(); after all, when you are closing a file descriptor, the useful work has generally been accomplished. But a close can return a failure code. This code does not generally refer to the close operation itself (which must succeed); instead, it can be used to indicate a failure in some other, perhaps related device operation. A CDROM driver could return a failure status if it is unable to unlock the drive door, for example. Other devices may still have operations outstanding, and the return value from close() is the only way to report problems with those operations. Inside the kernel, close() maps to a function called release() in the file_operations structure. That function, too, has a return value. So Axel Kittenberger was surprised to find out that there was no connection between the release() return value and what the application gets back from close(). Instead, that value is discarded, and close() always succeeds. He has posted a patch which fixes the situation by passing the release() return value through. Not everybody agrees that this is the right thing to do, interestingly. It has been stated that the fsync() call should be used by applications which are interested in any last-minute errors. But that approach doesn't address errors that happen in the close process itself. It is also a little strange to have return values from the operation that do not mean anything. So, while there are people who suggest that the release() function should be changed to return void, it's probably more likely that this patch will be applied. Straightening out the header files. People who dig around in the kernel source code tend to notice one thing early on: the header files are a bit of a mess. Figuring out which headers to include - and in which order - can be a pain. And it often seems necessary to include a large number of (seemingly) unrelated files to get a piece of code to compile. Daniel Phillips has started attacking one of the header file problems: the unstructured intermixing of definitions of data structures and the functions that use those structures. Many of the header files have "evolved" over time into fairly long and twisted things; programmers have thrown new definitions in over the years, often without any sort of overall design for the header file itself. Numerous problems have their roots in this untidiness, but Daniel has picked out one in particular: it can be hard to define inline functions that use certain kernel data structures. Such functions often get defined before the structures they reference; this, of course, does not work if the function needs to know anything specific about the data structure. Rearranging the definitions can be hard, so programmers tend to give up on inline functions and fall back on the use of macros. Macros work, but they are inelegant, and, crucially, they do not offer the same sort of type checking that inline functions do. The solution, according to Daniel, is to split out the definitions of fundamental data structures into their own header files. These small headers can then be placed early in the list of files to include, and their structures are available for use in inline functions later. He has posted a patch which makes this change for struct page, a fundamental data structure used in the management of physical memory. This change allows a couple of former macros (_pa, which converts kernel-space virtual addresses to physical addresses, and _va, which does the opposite) into inline functions. Says Daniel: As soon as I had the inline version of __pa, it picked up an oversight where Jeff [Dike] uses virtual addresses in his page tables instead of physical addresses. It works in the case of uml, but it's quite unexpected and has only gone unnoticed this long because of weak type checking due to use of macros.
The code changes required for this sort of patch are not small, since a fair amount of rearranging can be required. It appears that it may be worth the effort, though. For any ambitious folk who would like to take on other kernel headers, Daniel has posted his algorithm for accomplishing the task. It is, he says, "slightly painful, but not horribly excruciatingly painful." With such inspirational words, who can resist the urge to jump in and help out? Other patches and updates released this week include: Kernel trees:
Core kernel code:
Device drivers
Filesystems:
Kernel building:
Miscellaneous:
Ports:
Section Editor: Jonathan Corbet |
March 28, 2002
| ||
Copyright © 2002
Eklektix, Inc., all rights reserved
Next: Distributions