Linus has released 2.6.30 of the kernel, list of changes are available in the Linux Kernel Newbies guide.
This version adds the log-structured NILFS2 filesystem, a filesystem for object-based storage devices, a caching layer for local caching of NFS data, the RDS protocol which delivers high-performance reliable connections between the servers of a cluster, a distributed networking filesystem (POHMELFS), automatic flushing of files on renames/truncates in ext3, ext4 and btrfs, preliminary support for the 802.11w drafts, support for the Microblaze architecture, the Tomoyo security module, DRM support for the Radeon R6xx/R7xx graphic cards, asynchronous scanning of devices and partitions for faster bootup, MD support for switching between raid5/6 modes, the preadv/pwritev syscalls, several new drivers and many other small improvements.
One interesting change (amongst the many) is that we have this new feature called Fastboot. Essentially, when we boot right now, there is significant cycles wasted waiting for the device probing to complete. From Johnathan Corbet’s article on LWN:
There are many aspects to the job of making a system boot quickly. Some of the lowest-hanging fruit can be found in the area of device probing. Figuring out what hardware exists on the system tends to be a slow task at best; if it involves physical actions (such as spinning up a disk) it gets even worse. Kernel developers have long understood that they could gain a lot of time if this device probing could, at least, be done in a parallel manner: while the kernel is waiting for one device to respond, it can be talking to another. Attempts at parallelizing this work over the years have foundered, though. Problems with device ordering, concurrent access, and more have adversely affected system stability, with the inevitable result that the parallel code is taken back out. So early system initialization remains almost entirely sequential.
This new release attempts to address this problem.
Arjan hopes to succeed where others have failed by (1) taking a carefully-controlled approach to parallelization which doesn’t try to parallelize everything at once, and (2) an API which attempts to hide the effects of parallelization (other than improved speed) from the rest of the system. For (1), Arjan has limited himself to making parts of the SCSI and libata subsystems asynchronous, without addressing much of the rest of the system. The API work ensures that device registration happens in the same order is it would in a strictly sequential system. That eliminates the irritating problems which result when one’s hardware changes names from one boot to the next.
How well it does it, I guess we’ll have to wait and see. But here’s a bit of a tidbit in the kernel for the new Microblaze implementation.
void __init setup_cpuinfo(void)
{
struct device_node *cpu = NULL;
cpu = (struct device_node *) of_find_node_by_type(NULL, "cpu");
if (!cpu)
printk(KERN_ERR "You don't have cpu!!!\n");
printk(KERN_INFO "%s: initialising\n", __func__);
DUDE, You dont’ have cpu!!!
{lang: 'en-GB'}
