|
|
Subscribe / Log in / New account

3.13 Merge window, part 2

By Jonathan Corbet
November 20, 2013
The 3.13 merge window appears to be winding down, despite the fact that, as of this writing, it should have the better part of a week yet to run. There are now just over 9,900 non-merge changesets that have been pulled for 3.13; that is about 3,300 since last week's summary. Given the patch count and its slowing rate of increase, there is a good chance that Linus will close the merge window short of the full three weeks that had been expected this time around. It turns out that even diving trips on remote islands with bad Internet service can't slow the kernel process that much.

Some of the interesting user-visible changes pulled since last week's summary are:

  • The multiqueue block layer patch set has been merged at last. This code will pave the way toward cleaner, higher-performing block drivers over time, though the conversion of drivers has not really begun in 3.13.

  • The ARM big.LITTLE switcher code has been merged, providing basic support for heterogeneous ARM-based multiprocessor systems.

  • The ARM "BE8" big-endian subarchitecture is now supported.

  • The kernel has a new "power capping framework" allowing administrator control of peripherals which can implement maximum power consumption limits. Initially, support is limited to devices implementing Intel's "Running Average Power Limit" mechanism. See Documentation/power/powercap/powercap.txt for an overview of this subsystem and Documentation/ABI/testing/sysfs-class-powercap for details on the sysfs control interface.

  • The new "tmon" tool can be used to monitor and tweak the kernel's thermal management subsystem.

  • The split PMD locks patch set has been merged into the memory management subsystem. This code should result in significantly better performance in settings with a lot of transparent huge page use.

  • The ability to wait when attempting to remove a module whose reference count has not yet dropped to zero has been disabled. This feature, accessible via rmmod --wait, has been deprecated for the last year.

  • The size of huge pages on the SPARC64 architecture has changed from 4MB to 8MB. This change was necessary to enable this architecture to support up to 47 bits of physical address space. SPARC64 also supports the full tickless mode in 3.13.

  • New hardware support includes:

    • Block: STEC, Inc. S1120 PCIe solid-state storage devices. Also note that the Compaq Smart Array driver has been disabled in this release; it will be removed altogether unless somebody complains.

    • Graphics: Marvell Armada 510 LCD controllers. Also: the radeon driver now supports dynamic power management by default on a range of newer chipsets.

    • I2C: Samsung Exynos5 high-speed I2C controllers, STMicroelectronics SSC I2C controllers, and Broadcom Kona I2C adapters.

    • Input: Microsoft Hyper-V synthetic keyboards, Neonode zForce infrared touchscreens, and LEETGION Hellion gaming mice.

    • Miscellaneous: ARM Versatile Express serial power controllers, Freescale i.MX6 PCIe controllers, Renesas R-Car Gen2 internal PCI controllers, TPO TD028TTEC1 LCD panels, ST Microelectronics STw481x power management chips, AMS AS3722 power management chips, and TI BQ24735 battery chargers.

    • Video4Linux: Conexant CX24117 dual DVB-S/S2 tuner modules, TI video processing engines, TI LM3560 dual-LED flash controllers, and ST Micro remote controls.

    • Watchdog: MOXA ART watchdog timers, Ralink SoC watchdog timers, and CSR SiRFprimaII and SiRFatlasVI watchdog timers.

Changes visible to kernel developers include:

  • The new helper function:

        int dma_set_mask_and_coherent(struct device *dev, u64 mask);
    

    Will attempt to set both the streaming (non-coherent) and coherent DMA masks for the given device. Many drivers have been converted to this function, often with bugs fixed along the way.

  • Most locking-related code has been moved into the new kernel/locking subdirectory.

  • printk() and friends no longer implement the "%n" directive, which was seen as an invitation to security problems.

  • The confusingly-named INIT_COMPLETION() macro, part of the completion mechanism, has been renamed to reinit_completion(). Its purpose has always been to reinitialize a completion that has already been used at least once; the new name should make that clearer.

  • The new set_graph_notrace tracing filter allows the selective pruning of subtrees from graph trace output. See the commit changelog for an example of how this feature works.

Next week's LWN Kernel Page will contain an update with the final changes merged for the 3.13 kernel, which, most likely, will be released around the end of the year.

Index entries for this article
KernelReleases/3.13


to post comments

3.13 Merge window, part 2

Posted Nov 21, 2013 21:45 UTC (Thu) by intgr (subscriber, #39733) [Link]

> the Compaq Smart Array driver has been disabled in this release; it will be removed altogether unless somebody complains

My jaw dropped when reading this. But it turns out they're only dropping the "cpqarray" driver for really old RAID cards; more recent Smart Array controllers are still supported by the cciss driver.

See https://lkml.org/lkml/2013/10/17/402

3.13 Merge window, part 2

Posted Nov 23, 2013 20:32 UTC (Sat) by viro (subscriber, #7872) [Link]

Another kernel-side change is that filesystems need to be ready to cope with RCU-pathwalk looking at the dentries of a filesystem in the middle of being shut down; what it means in practice is that if your fs has any kind of fs-wide data structures used by ->d_hash(), ->d_compare(), ->d_revalidate() (with LOOKUP_RCU in flags), ->d_manage() (with the 'rcu_walk' argument being true) or ->permission() (with MAY_NOT_BLOCK in mask), you need to make sure that they are not destroyed without RCU delay. For most of filesystems it doesn't require any changes whatsoever. When it does, it's usually just a matter of RCU-delaying the actual freeing of whatever they have in sb->s_fs_data. As the last resort, one could simply slap synchronize_rcu() in ->kill_sb() or ->put_super(), but that's slower and none of the in-tree filesystems had to do it that way. Note that freeing of struct super_block itself is RCU-delayed, so fs doesn't have to worry about that one.

See commits e2fec7c..dd3e2c55 for such conversions for in-tree filesystems...


Copyright © 2013, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds