In brief

Hyper-V. Very few kernel submissions draw as much attention as Microsoft's contribution of its Hyper-V drivers to the staging tree. The drivers enable the virtualization of Linux under Windows, a feature which some find useful. In general, reactions included surprise and concern, and at least one prediction of immediate and utter doom. Much of the development community, though, treated it like just another patch submission. The quality of the code is not held to be great, but fixing such things up is what the staging tree is for.

For the curious, a little bit of history behind this submission can be found in this weblog posting by Stephen Hemminger.

VFAT. Andrew "Tridge" Tridgell is back with a new set of VFAT patches aimed at working around the patents being asserted against that filesystem. He has made progress in addressing the interoperability problems reported by testers, though a few small issues remain. As always, he's looking for testers who can identify any remaining problems with the patch.

Checkpoint/restart. Oren Laadan has posted a new set of checkpoint/restart patches which, he says, is "already suitable for many types of batch jobs." The patch adds a new clone_with_pids() system call allowing restored processes to be created with the same process ID they had at checkpoint time; it's not clear whether the security concerns with that capability have been addressed or not. There are still plenty of open issues with checkpoint/restart, including pending signals, FIFO devices, pseudo terminals, and more. It's a messy problem to try to solve, but this patch set seems to be getting closer. There's instructions in the patch for those who would like to experiment with it.

Flexible arrays. Kernel developers often find themselves needing to allocate multi-page chunks of contiguous memory. Typically such allocations are done with vmalloc(), but that solution is not ideal. The address space for vmalloc() allocations is restricted (on 32-bit systems, at least), and these allocations are rather less efficient than normal kernel memory allocations.

Responding to a request from Andrew Morton, Dave Hansen has proposed the addition of a flexible array API to the kernel. Flexible arrays would handle large allocations, but, under the hood, they use single-page chunks which can be allocated in a normal (and reliable) fashion. In brief, a flexible array is created with:

    struct flex_array *flex_array_alloc(int element_size, int total, 
    	   	      			gfp_t flags);

Once the array is created, data can be moved into and out of it with:

    int flex_array_put(struct flex_array *fa, int element_nr, void *src, 
    		       gfp_t flags);
    void *flex_array_get(struct flex_array *fa, int element_nr);

There's a number of other functions for freeing parts of an array, preallocating memory, etc.; see the patch posting for the full API.

Coarse clocks. Some applications want to get access to the system time as quickly as possible, but they are not concerned about obtaining absolute accuracy. To fill this need, John Stultz has proposed a couple of new clock types: CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE. In essence, these clocks work by returning the system's latest idea of the current time without actually asking any hardware. The idea was reasonably well received, with one concern: developers would hate to see this feature become one more obstacle to removing the periodic clock tick (and jiffies) in the future. This removal is far from imminent - there's a lot of work to be done first - but it remains desirable for a number of reasons.

---

(Log in to post comments)