A summary of 2.6.20 API changes [LWN.net]

As of this writing the final 2.6.20 kernel has not yet happened. It is close, however. Since any internal API changes meant for 2.6.20 should have happened at least a month ago, it should be safe to put a summary of the most significant changes. There have been a few of them in this kernel cycle, some of which caused widespread churn through the code base.

The workqueue API has seen a major rework which requires changes in almost any code using workqueues. In short: there are now two different types of workqueues, depending on whether the delay feature is to be used or not. The work function no longer gets an arbitrary data pointer; its argument, instead, is a pointer to the work_struct structure describing the job. If you have code which is broken by these changes, this set of instructions by David Howells is likely to be helpful.
Some additional workqueue changes have been merged as well. There is a new "freezable" workqueue type, indicating a workqueue which can be safely frozen during the software suspend process. The new function create_freezeable_workqueue() will create one. Another new function, run_scheduled_work(), will cause a previously-scheduled workqueue entry to be run synchronously. Note that run_scheduled_work() cannot be used with delayed workqueues.
Much of the sysfs-related code has been changed to use struct device in place of struct class_device. The latter structure will eventually go away as the class and device mechanisms are merged.
There is a new function:
```
    int device_move(struct device *dev, struct device *new_parent);
```
This function will reparent the given device to new_parent, making the requisite sysfs changes and generating a special KOBJ_MOVE event for user space.
A number of kernel header files which included other headers no longer do so. For example, <linux/fs.h> no longer includes <linux/sched.h>. These changes should speed kernel build times by getting rid of large number of unneeded includes, but might break some out-of-tree modules which do not explicitly include all the headers they need.
The internal __alloc_skb() function has a new parameter, being the number of the NUMA node on which the structure should be allocated.
The slab allocator API has been cleaned up somewhat. The old kmem_cache_t typedef is gone; struct kmem_cache should be used instead. The various slab flags (SLAB_ATOMIC, SLAB_KERNEL, ...) were all just aliases for the equivalent GFP_ flags, so they have been removed.
A new boot-time parameter (prof=sleep) causes the kernel to profile the amount of time spent in uninterruptible sleeps.
dma_cache_sync() has a new argument: the device structure for the device doing DMA.
The paravirt_ops code has gone in, making it easier for the kernel to support multiple hypervisors. Anybody wanting to port a hypervisor to this code should note that it is somewhat volatile and likely to remain that way for some time.
The struct path changes have been merged, with changes rippling through the filesystem and device driver subsystems. In short, code accessing the dentry pointer from a struct file pointer, which used to read file->f_dentry, should now read file->f_path.dentry. There are defines making the older style of code work - for now.
There is now a generic layer for human input devices; the USB HID code has been switched over to this new layer.
A new function, round_jiffies(), rounds a jiffies value up to the next full second (plus a per-CPU offset). Its purpose is to encourage timeouts to occur together, with the result that the CPU wakes up less frequently.
The block "activity function," a callback intended for the implementation of disk activity lights in software, has been removed; nobody was actually using it.

For those looking forward to what might happen in 2.6.21, a couple of significant changes can be predicted. The old SA_* flags used with request_irq() are likely to go away; the newer IRQF_* flags should be used instead. There is also a timer API change waiting for the next development cycle. Beyond that, a surprise or two is guaranteed; watch LWN for the details as the patches get merged.

(Log in to post comments)