Recent patches of interest
Nigel Cunningham has been working at getting some small pieces of his software suspend implementation into the kernel. One of those pieces is this patch, which has to do with the "freezing" of kernel threads prior to suspending the system. As processes are put on hold, the kernel risks stopping a process which is needed later on in the suspend process; think about a process handling NFS service or software interrupts, for example. To avoid this situation, kernel threads are simply not frozen. But many of them can be, and that would make the suspend process more robust. So Nigel's patch goes through and tries to set up each thread with the appropriate flags, so that only truly necessary kernel threads continue to run while the system is being suspended.
A number of these threads, it turns out, are part of a workqueue. As a way of setting up every workqueue process with the right flags, Nigel changed the interface to create_workqueue() and create_singlethread_workqueue(), thus breaking all code which creates its own workqueues. Andrew Morton expressed some discomfort at the API change, but acknowledged that it was useful in that it forces people to think about whether every workqueue needs to run during a system suspend operation or not. This patch has not yet appeared in -mm, as of this writing.
Rik van Riel and Arjan van de Ven have put together a new patch which allows normal users to lock memory into physical RAM without root privilege. The RLIMIT_MEMLOCK resource limit puts an upper bound on how much memory can be locked, and its default value is zero. By raising this limit, system administrators can enable users to lock a single page (useful for cryptographic applications which do not want to see passphrases and clear text swapped to disk) or larger amounts (for CD writing tasks, for example). Various issues were raised regarding the security of this patch, but the latest version appears to have resolved them. This code should eventually replace the magic "mlock group" hack that was covered here last May.
Fistgen 0.1 has been released; this is the first version for the 2.6 kernel. The announcement describes fistgen as "a package of stackable templates," which may not be particularly illuminating to many readers. More information can be found at filesystems.org; one developer calls it "a yacc for filesystems." Using fistgen and a small amount of code, a set of filters can be set up to create a filesystem with a given set of characteristics. For example, this template describes a filesystem which encrypts data using the sophisticated "rot13" algorithm. The fistgen parser reads the template file and generates C code implementing the filesystem, which can then be loaded into the kernel.
John McCutchan has been working on his inotify patch for some time. Inotify is meant to be a replacement for the dnotify mechanism, used by processes which wish to be alerted when files are changed. The inotify patch takes a different approach; it creates a char device which supports a small set of ioctl() operations. After opening this device and using ioctl() to express interest in a particular set of files, a process need only read the device to get the change events for those files.
OpenSSI 1.0 is out. OpenSSI is a "single system image" clustering environment based on the 2.4 kernel; it includes member ship functions, the CFS and Lustre Lite filesystems, process management, and a cluster-wide device mechanism built on devfs. See the OpenSSI web page for more information.
The sysfs directory /sys/module contains, among other things, attributes for parameters exported by loaded modules. Dominik Brodowski noticed that, if these modules are built directly into the kernel, those parameters are not available via sysfs. If they were, they shouldn't be under /sys/module in any case, since the code in question is not part of a module. So he has posted a patch creating a new directory (/sys/parameters) and putting attributes there, for both modules and built-in code. This is a user-space API change, but it is unlikely that anything of any consequence depends on parameters under /sys/module at this point.
Jens Axboe has posted a new SCSI generic ("sg")
implementation (called "bsg") which works through the block layer. This driver
implements the SG_IO ioctl() call, and also allows
communication through regular reads and writes. The latter functionality
caused some complaints; when structures are passed between user and kernel
space with read() and write() calls, it becomes very hard
to convert them when the process is running in 32-bit mode on a 64-bit
platform. For all that the developers dislike ioctl(), that
interface does, at least, make it clear when and where a structure is being
transferred across the user-kernel boundary. To address these complaints,
the bsg driver may be restricted to the ioctl() mode only.
Posted Aug 5, 2004 13:18 UTC (Thu)
by jsm (guest, #4011)
[Link]
For people interested in testing Inotify all you need to do is get gamin (an API/ABI stable FAM replacement) from gnome's cvs servers. It has an inotify backend.Inotify