LWN.net Logo

2.6.31 merge window, week 1

By Jonathan Corbet
June 17, 2009
The process of merging patches for 2.6.31 has begun. As of this writing, 6220 non-merge changesets have been added to the mainline. Some of the more interesting, user-visible change include:

  • Reads from /dev/zero can now be interrupted by signals. In theory, no application should be adversely affected by this change, but is still a true user-space ABI change.

  • The x86 architecture can now handle 46-bit physical addresses, allowing the use of up to 64TB of physical memory.

  • A number of Xen features meant to support Dom0 functionality (the /dev/xen/evtchn event channel code ant /sys/hypervisor, for example) have been merged. The Dom0 code itself remains outside, though.

  • Support for the rt_tgsigqueueinfo() system call, which sends a signal (with ancillary information) to a thread group, has been added.

  • A number of ftrace features have been added. These include a function profiler, a number of event tracer improvements, some new tracepoints, and a new docbook document describing static tracepoints in the kernel.

  • The USB TTY port driver has been reworked in ways which bring it into closer alignment with POSIX behavior and that of other types of serial ports. Alan Cox fears that some applications which depended on the old behavior might break - though others, which had problems with USB serial ports, should now begin to work.

  • There is a new sysctl knob (/proc/sys/kernel/modules_disabled); writing "1" to that file will cause module loading to be forevermore disallowed.

  • The SMACK security module now has a comprehensive logging facility.

  • The splice() system call now works when both the input and output files are pipes.

  • The storage topology patches (covered briefly in April) have been merged. This code allows the kernel to export much more information about how storage devices are structured, enabling support for upcoming hardware.

  • The performance counters patch set (last covered in December) have been merged. This code provides a new API for the use of hardware performance counters; it edges out perfmon and a number of other implementations in this area.

  • The character devices in user space (CUSE) patch set has been merged.

  • arch-imx has been removed from the ARM architecture as it has been superseded by the MXC architecture.

  • The s390 architecture has added support for dynamic ftrace, as well as the system call and function graph tracers.

  • The packet_mmap changes for the transmission side of packet sockets was merged, which allows for more efficient, nearly zero-copy, packet sends from user space.

  • The controller area network (CAN) subsystem has added a network device driver interface and a netlink interface. New CAN device drivers have also been merged using the driver interface (see below).

  • Support for IEEE 802.15.4 sockets has been added to the network subsystem. This is for low-cost, low-speed "personal area networks".

  • Passive OS fingerprinting has been added to the netfilter code.

  • The FAT filesystem has added an "errors" mount option which governs its behavior in the presence of critical errors.

  • The s390 architecture has added support for hibernation.

  • Support has been added for USB 3.0/xHCI host controllers, though none are yet available.

  • Kernel modesetting for the radeon driver, supporting R1XX, R2XX, R3XX, R4XX, R5XX, and radeon up to X1950 hardware, has been merged.

  • There is the usual pile of new drivers:

    • Architectures/processors/systems: SuperH SH7724 processors, Hitachi SH7724 (SolutionEngine7724) boards, memory error detection and correction (EDAC) support for AMD K8, F10h, and F11h processors, ARM PCM043 boards, ARM Atmark Armadillo 500 boards, OMAP3 Zoom2 boards, OMAP4430 SDP boards (including SMP support), ARM MX35PDK boards, Marvell 88F6281 GTW GE boards,Samsung S3C6400 SoCs, ARMv6/v7 big-endian, Stargate 2 boards, Freescale STMP platforms, ST-Ericsson U300 series platforms, PowerPC MPC8569MDS boards, PowerPC P2020DS boards.

    • Miscellaneous: Timberdale FPGA UARTs, 64-bit VIA hardware random number generators, Mediama RMTx add-on board for ATNGW100, Wacom Graphire Bluetooth tablet, CB710/720 memory card readers, Maxim 1586 voltage regulators, TI TMP401 temperature sensor, Intel Langwell USB device controllers, Intel Langwell USB On-the-go controllers, TI VLYNQ bus, ST Microelectronics DDC I2C interface.

    • Networking: Broadcom NetXtremeII gigabit Ethernet cards (offload features in particular), Intellon PLC (Powerline communications) USB adapters, Marvell SD8688 wireless chips, Ralink rt2800 wireless USB chipsets, TI wl1251/wl1271 wireless chipsets, TI DaVinci Ethernet MACs, Phillips SJA1000 CAN controllers, Kvaser PCIcanx and Kvaser PCIcan PCI CAN Cards, Intel wireless Multicomm 3200 devices, Micrel KS8842 ethernet switches.

    • Sound: Wolfson Micro WM8988, WM8940, WM9081, and WM8960 codecs, Digigram LX6464ES boards, ESI Maya44 boards, several Creative Sound Blaster X-FI devices based on the 20K1 and 20K2 chipsets, a USB Audio gadget driver.

    • Graphics: AMD r600 chipset, Intel IGDNG chipset.

    • Video: DVB-S/S2/DSS Multistandard Professional/Broadcast demodulators, STV6110/(A) based tuners, ISL6423 SEC controllers, TI THS7303 video amplifiers, Analog Devices I2C bus based ADV7343 encoders.

Changes visible to kernel developers include:

  • There is a new atomic function:

        int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock);
    

    This function will decrement cnt and, if cnt reaches zero, it will acquire the given lock.

  • A number of block layer request queue API changes have been merged; all drivers must now dequeue requests before executing them. Beyond that, the merging of the storage topology patches (in preparation for 4K-sector disks) mean that block drivers must now distinguish between the physical block size on the disk and the logical block size used by the kernel.

  • The 32-bit x86 architecture now supports the atomic64_t type.

  • The kernel memory leak detector has been merged at last.

  • The fsnotify backend has been merged. This code provides a new, common implementation for dnotify and inotify; it also will serve as the base for the "fanotify" code (formerly TALPA), which has not been merged as of this writing.

  • Btrfs has seen a number of enhancements, including one which involves an on-disk format change. Existing btrfs filesystems will work with the new code, but, once mounted on a 2.6.31 system, those filesystems will no longer work with older kernels.

  • Tree read-copy update (RCU) is now the default, though Classic RCU is still available.

  • Changes to the include/asm-generic header files were merged. These changes are meant to serve as a model for or be used directly by new architectures rather than copying from an existing architecture. The S+core (score) architecture depends on these changes and the MicroBlaze architecture will be using them to clean up its ABI.

  • Some rather large cleanups for XFS were merged, including switching to the generic POSIX ACL code and removal of the xfs_qmops quota ops function vector.

  • All network drivers have converted to the new net_device_ops API and the old API available with COMPAT_NET_DEV_OPS has been removed.

  • The rfkill core has been rewritten for devices that implement a way to stop all radio transmission from the device (in response to a laptop key for turning off wireless, for example). Various drivers have also been updated to use the new rfkill API.

  • Debugfs has had all of its references throughout the tree turned into /sys/kernel/debug/ in both documentation and code. In addition, LWN's updated guide to debugfs was added to the Documentation directory.

  • Unicode handling in the kernel has been updated, with functions like utf_mbstowcs() being renamed to utf8s_to_utf16s() for better readability.

  • The kmemcheck kernel memory checker to detect the use of uninitialized memory has been merged.

  • The TTM GPU memory manager (covered a bit over a year ago) has been merged.

Linus started merging patches on June 10, suggesting that the merge window will remain open until sometime around June 24. That puts us roughly half way through the merge window, in terms of time. The merge rate will likely slow down some for the remainder of the merge window, but there are, undoubtedly, more interesting changes to come. Stay tuned.


(Log in to post comments)

This one intrigues me in a perverse way

Posted Jun 18, 2009 3:58 UTC (Thu) by felixfix (subscriber, #242) [Link]

The s390 architecture has added support for hibernation.

I suppose this is so a mainframe can go to sleep when you open a maintenance door instead of close its lid.

This one intrigues me in a perverse way

Posted Jun 18, 2009 11:12 UTC (Thu) by epa (subscriber, #39769) [Link]

Either that or Big Blue is about to launch an S/390-based iPhone killer.

This one intrigues me in a perverse way

Posted Jun 23, 2009 13:18 UTC (Tue) by Baylink (subscriber, #755) [Link]

Damnit. Not only did you beat me to the joke, you did almost exactly the same one I was gonna do.

No, wait:

"So that when you close the lid on your mainframe, it takes less power while it's asleep."

:-)

I do wonder, though: why do 390 arch machines need to hibernate? Or is this for things like native virtualization...

2.6.31 merge window, week 1

Posted Jun 18, 2009 8:17 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

I like the cuse thing - the walls between microkernel and monolithic are starting to come down, and people can put things in user or kernel space as they make sense. Now we just need to be able to handle IRQs and DMA in userspace drivers.

Interesting that TTM is being merged - I thought it was on the way out.

TTM

Posted Jun 18, 2009 9:34 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

TTM's API was found to be inadequate for the Intel hackers. But the functional guts of it were still desired by the hackers working on ATI and nV hardware. So the resolution as I understand it is TTM's code lives on, but the API now resembles what was desired by Intel.

2.6.31 merge window, week 1

Posted Jun 18, 2009 8:31 UTC (Thu) by Tuxie (guest, #47191) [Link]

Yay for CUSE! Now we will finally be able to get perfect OSS emulation through the standard ALSA/dmix/Pulseaudio/JACK plugin chains. It's not as important as it was a year or more ago, but there are still plenty of old games and emulators that only support OSS, or have buggy (not compatible with PA/JACK/dmix) ALSA support but also support OSS.

2.6.31 merge window, week 1

Posted Jun 18, 2009 12:09 UTC (Thu) by smorovic (guest, #52892) [Link]

If kernel is recompiled without OSS emulation support, CUSE and ossp will work (otherwise a device number is reserved). However emulation will still not be perfect (impossible to match latency of direct writes to sound card buffers while OSS API doesn't do adequate latency information feedback to the application), but at least I expect it to work better with some old and/or proprietary apps than current userspace emulation.

2.6.31 merge window, week 1

Posted Jun 18, 2009 10:57 UTC (Thu) by iznogood (guest, #51845) [Link]

Don't get me wrong but so far this seems like the most boring kernel release in the last 2-3 years. With the exception of TTM and ATI KMS most of the changes look like internal reorganization. Lets see whats coming next week.

Also whats happening in rt land ?? What about threaded interrupt handlers or preemptible spinlocks ??

YMMV as usual

Posted Jun 18, 2009 11:51 UTC (Thu) by khim (subscriber, #9252) [Link]

As was already pointed out CUSE means it's first kernel usable for real-word hardware and real world programs in a long-long-long time. Five years? Seven years? Something like that...

Sure, some things are more exciting then others but just because you can not find anything to be excited about does not mean it's boring...

YMMV as usual

Posted Jun 20, 2009 12:42 UTC (Sat) by sbergman27 (subscriber, #10767) [Link]

"""
As was already pointed out CUSE means it's first kernel usable for real-word hardware and real world programs in a long-long-long time. Five years? Seven years? Something like that...
"""

What?!

Easy: OSS emulation

Posted Jun 20, 2009 13:21 UTC (Sat) by khim (subscriber, #9252) [Link]

Real-world programs (Acrobat Reader, Quake, Skype, etc) do use OSS. Today's real-world hardware does not have hardware mixer - and that means without CUSE there are no way to use these programs and keep all dekstop sound effects players and other things around. Looks like FOSS developers are slowly learn that "just use never version and/or recompile it" is not an acceptable answer to compatibility problems. I've written about it before

Easy: OSS emulation

Posted Jun 20, 2009 14:22 UTC (Sat) by sbergman27 (subscriber, #10767) [Link]

So you have an old sound card somewhere that CUSE helps in some way when used with certain proprietary software.

Sure, some things are more boring than others. But just because you've found something, contrived as it may be, to get excited about does not mean it's exciting to others.

I'm not taking a position as to whether this kernel is shaping up to be "boring" or not. To me it's just another kernel development cycle. One of many in a long line of them. It's the cumulative progress that matters.

2.6.31 merge window, week 1

Posted Jun 18, 2009 13:54 UTC (Thu) by tajyrink (subscriber, #2750) [Link]

All us Phoronix / graphics junkies are bouncing with joy of being able to try out KMS / TTM on Radeon using Linus' kernel, so it's not a small thing.

Now if R600/R700 KMS support + Nouveau KMS would get in 2.6.32, things would get exciting.

2.6.31 merge window, week 1

Posted Jun 18, 2009 11:40 UTC (Thu) by rfrancoise (subscriber, #15508) [Link]

Where applicable it would be nice to have links to the relevant Git commits in such articles.

2.6.31 merge window, week 1

Posted Jun 18, 2009 13:15 UTC (Thu) by shapr (guest, #9077) [Link]

As someone said in a previous comment, links to the relevant git commits would be handy.

I'm running Linux on IBM HS21 blades with Broadcom NetXtreme II BCM5708S Gigabit Ethernet NICs. I'd like to know more about the new features.

2.6.31 merge window, week 1

Posted Jun 18, 2009 13:47 UTC (Thu) by amd (guest, #37690) [Link]

There was also a complete rfkill-rewrite...

2.6.31 merge window, week 1

Posted Jun 18, 2009 15:55 UTC (Thu) by spotter (subscriber, #12199) [Link]

how are reads to /dev/zero being interruptable by a signal an abi change?

i.e. any program that ran b4 will still run, it could just be caused to execute along a different path, that doesn't seem like an ABI change to me, but perhaps I'm confusing the term.

2.6.31 merge window, week 1

Posted Jun 19, 2009 2:30 UTC (Fri) by jamesh (guest, #1159) [Link]

If a read is interrupted by a signal, then it is cut short. So if an application was reading from /dev/zero but not prepared to handle a short read, then it could break with the newer kernel.

Whether such applications exist is open to debate.

2.6.31 merge window, week 1

Posted Jun 19, 2009 2:39 UTC (Fri) by spotter (subscriber, #12199) [Link]

I understand that. But that seems like a change in API semantics, not in the ABI.

2.6.31 merge window, week 1

Posted Jun 19, 2009 11:51 UTC (Fri) by jamesh (guest, #1159) [Link]

The API semantics can make up part of the ABI.

As an example, most people would consider changing the open() system call to return a random integer to be an ABI break. With such a change, the system call would still be take the same arguments and have the same return type so the change is arguably one of semantics.

/dev/zero: ABI change?

Posted Jun 20, 2009 0:19 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

Never mind API semantics. It's an ABI semantic change.

The only difference between an API and an ABI is that the API applies to source code and the ABI applies to the executable ("binary", e.g. ELF file).

An API change means that source code that used to be able to expect a certain behavior, once compiled and run, can't anymore.

An ABI change means that an executable that used to be able to expect a certain behavior when run, can't anymore.

The behavioral change might be that the program used to run and now won't even start because the format of the ELF header changed, but it might also be that the kernel returns half the requested data for a read() where it returned all of it before.

/dev/zero: ABI change?

Posted Jun 21, 2009 2:09 UTC (Sun) by spotter (subscriber, #12199) [Link]

ok, you're right, I buy that explanation.

Preventing future module loading

Posted Jun 20, 2009 16:06 UTC (Sat) by ttfkam (guest, #29791) [Link]

Hopefully now the choice between flexibilty and security is becoming more like having cake
and eating it too.

Preventing future module loading

Posted Jun 21, 2009 8:14 UTC (Sun) by nix (subscriber, #2304) [Link]

Finally I can drop my ugly module_seal patch, rightfully rejected years
ago, in favour of this one (which uses an identical API except for the
name of the special file you echo 1 to).

Yay, one less patch to drag around.

Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds