|
|
Subscribe / Log in / New account

3.18 Merge window part 1

By Jonathan Corbet
October 8, 2014
Linus had stated his intent to take a week off from merging patches before starting the 3.18 merge window around October 12. Even so, somehow, a few thousand (2936, to be precise) changesets showed up in the mainline repository when nobody was looking. The initial pulls have a focus toward driver code (including the staging tree), but there are a few other items in the mix as well.

User-visible changes merged so far include:

  • The arm64 architecture now has support for just-in-time compilation of extended Berkeley packet filter (eBPF) programs.

  • The cryptographic layer has gained support for multibuffer operations. The idea here is to use parallel hardware operations to perform the same transform on multiple buffers concurrently. In 3.18, there is an implementation of SHA1 that can make use of this feature.

  • The NFS server now supports the NFS 4.2 SEEK operation, allowing the implementation of the Linux SEEK_HOLE and SEEK_DATA lseek() options.

  • The F2FS filesystem supports atomic writes (where a series of operations succeeds or fails as a unit) via filesystem-specific ioctl() operations. F2FS has also gained support for the FITRIM (discard) operation.

  • New hardware support includes:
    • Human input/output: PenMount 6000 touch controllers, TI DRV260X and DRV2667 haptic controllers, TI Palmas power buttons, and MAXIM MAX77693 haptic controllers.

    • Miscellaneous: Freescale i.MX21 pin control units, Qualcomm APQ8084 pin controllers, Broadcom BCM53xx SPI controllers, APM X-Gene true random number generators, Maxim MAX5821 digital-to-analog converters, Bosch BMC150 accelerometers, Bosch BMG160 tri-axis gyro sensors, Texas Instruments ADC128S052 analog-to-digital converters (ADCs), Rockchip SARADC ADCs, Dyna Image AL3320A ambient light sensors, Fintek F81216A LPC to 4 UARTs, Amlogic Meson serial ports, and Mediatek serial ports.

    • Regulators: Dialog Semiconductor DA9213 regulators, HiSilicon Hi6421 PMIC voltage regulators, Intersil ISL9305 regulators, Qualcomm RPM regulators, Maxim 77802 regulators, Rockchip RK808 power regulators, and Ricoh RN5T618 voltage regulators.

    • USB: Xilinx USB2 peripheral controllers, ST Microelectronics OHCI/EHCI controllers, Renesas R-Car generation 2 USB PHYs, STMicroelectronics USB2 picoPHYs, STMicroelectronics STiH41x USB transceivers, National Instruments USB-6501 controllers, and Richtek RT8973A USB port accessory detectors.

Changes visible to kernel developers include:

  • A few kernel "tinification" patches have been merged for those trying to build the smallest kernels possible. In 3.18 the table describing processor capability bits and the madvise() and fadvise() system calls can be configured out.

  • Module parameters can be defined with a new "unsafe" flag; any attempt to modify such a parameter will generate a warning and taint the kernel. The module_param_unsafe() macro can be used to set up such parameters.

  • Kernel modules can now be installed in compressed form by the build system.

  • The driver core has a new "device coredump" mechanism that can be used to obtain core dumps and other diagnostic information from peripheral devices. It is intended to be used as an aid for firmware debugging.

As can be seen, the 3.18 merge window has barely gotten started so far. The pace can be expected to pick up in the near future, once Linus completes his travels and arrives in Düsseldorf for LinuxCon / CloudOpen / ELCE / KVM Forum / LPC / etc.

Index entries for this article
KernelReleases/3.18


to post comments

SHA1 considered unsafe

Posted Oct 10, 2014 9:43 UTC (Fri) by Seegras (guest, #20463) [Link] (1 responses)

SHA1 considered unsafe

Posted Oct 10, 2014 9:55 UTC (Fri) by johill (subscriber, #25196) [Link]

That (the subject) is not really all that important in this context - sha-1 is used in lots of places and needs to be supported anyway so making it faster is helpful. Making better hashes faster would potentially be even more helpful, but it doesn't really mean optimising sha-1 is bad, as you seem to imply (or maybe I'm misunderstanding that)


Copyright © 2014, 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