|
|
Subscribe / Log in / New account

4.12 Merge window part 2

By Jonathan Corbet
May 10, 2017
As of this writing, nearly 12,000 non-merge changesets have been pulled into the mainline repository for the 4.12 development cycle. About 7,500 of these have been pulled since the first 4.12 merge-window summary. Read on for an overview of what has been merged in the last week.

The not-yet-complete 4.12 merge window looks likely to be one of the busiest ever. For the curious, recent history looks like this:

Changesets pulled during
the merge window
4.08,950
4.110,659
4.212,092
4.310,756
4.411,528
4.510,305
4.612,172
4.710,707
4.811,618
4.914,304
4.1011,455
4.1110,960
4.1211,869

Since the 4.12 merge window is not yet complete, the final number in that table is not actually final yet. There is a good chance that 4.12 will end up being the second-busiest merge window ever. On the other hand, 4.9 is likely to remain unchallenged in its position as the busiest for some time yet.

Some of the more interesting user-visible changes merged in the last week include:

  • The new GETFSMAP ioctl() command can be used to explore the physical extent mappings used within a filesystem. It can be used, for example, to determine which files contain a given physical block. This patch documents GETFSMAP. The XFS and ext4 filesystems will have support for GETFSMAP in 4.12.

  • The new "function-fork" tracing option will, when trace events are limited to a specific set of processes, cause any new child processes to be added to the set.

  • The 9pfs filesystem can now be used to transport data between multiple Xen domains.

  • The kernel finally has proper support for USB type-C connectors.

  • The PowerPC architecture can now support virtual address-space sizes up to 512TB. By default, though, processes are limited to 128TB; that limit can be raised by passing a hint to mmap() as described in this article.

  • The ARM64 architecture now has kernel crash-dump functionality.

  • KVM now supports the MIPS "VZ" virtualization mechanism. On the x86 architecture, KVM has dropped support for the device-assignment mechanism; all users should be using the VFIO interface instead.

  • Quite a bit of the activity in this merge window took the form of new device drivers; new hardware support includes:

    • Audio: RME Fireface 400 controllers, MOTU 828mk2 and 828mk3 controllers, Cirrus Logic CS35L35 amplifiers, Dioo DIO2125 amplifiers, Everest Semi ES7134 codecs, Hisilicon hi6210 I2S controllers, Maxim MAX98927 amplifiers, Nuvoton NAU8824 audio codecs, and STMicroelectronics STM32 digital audio interfaces.

    • Graphics: MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw display bridges, Generic LVDS panels, R-Car DU Gen3 HDMI encoders, Samsung S6E3HA2 DSI video mode panels, and Sitronix ST7789v controllers.

    • Industrial I/O: Devantech SRF04 ultrasonic range sensors, ChromeOS EC light and proximity sensors, Analog Devices ADXL345 3-axis digital accelerometers, Maxim MAX30102 heart rate and pulse oximeter sensors, Linear Technology LTC2632 digital-to-analog converters (DACs), Linear Technology LTC2497 analog-to-digital converters (ADCs), STMicroelectronics VL6180 sensors, Motorola CPCAP PMIC ADCs, Aspeed ADCs, Maxim max9611, max9612, max1117, max1118, and max1119 ADCs, Qualcomm SSBI PM8xxx PMIC crystal-oscillator ADCs, and STMicroelectronics STM32 DACs.

    • Media: Mediatek JPEG codecs, RainShadow Tech HDMI CEC controllers, and OmniVision OV5645 and OV5647 sensors.

    • Miscellaneous: Arctic Sand arc2c0608 backlight controllers, Freescale i.MX23/i.MX28 ADCs, TI lighting management units, Dialog Semiconductor DA9061 power-management ICs, X-Powers AXP20X and AXP22X ADCs, Analog Devices X-Powers AXP20X and AXP22X multiplexors, ROHM BD9571MWV regulators, ROHM BD9571 GPIO controllers, TI TPS65132 Dual Output Power regulators, TI TSC2007 touchscreen controllers, Technologic Systems TS-73xx SBC FPGA managers, Lattice iCE40 FPGAs, Aspeed ast2400/2500 host LPC to BMC bridge controllers, Maxim DS2438 battery monitors, Hitachi HD44780 character LCD controllers, Xilinx LogiCORE PR decouplers, Qualcomm Technologies L3-cache performance-monitoring units, Adafruit SH1106 LCD controllers, Intel image processing units (200,000 lines of new staging code), ARM TrustZone CryptoCell C7XX crypto accelerators, Palmchip BK3710 PATA controllers, Freescale i.MX7 system reset controllers, NVIDIA Tegra power management controllers, and MediaTek pulse-width modulators.

    • Networking: Intel Omni-Path virtual network interface controllers, Realtek RTL8723BS SDIO Wireless LAN NICs (109,000 lines of staging code), and Freescale DPAA2 Ethernet controllers.

    • PCI: Faraday Technology FTPCI100 PCI controllers and MicroSemi Switchtec PCIe switch management interfaces.

    • USB: Qualcomm QUSB2 and QMP PHYs and Fairchild FUSB302 type-C interfaces.

Changes visible to kernel developers include:

  • There is a new "virtual media controller" driver in the media subsystem. Like the "vivid" virtual camera device, it is meant to be a demonstration of the interfaces as well as a comprehensive test case.

  • The Android low-memory killer implementation has been removed from the staging tree.

  • The kvmalloc() allocation function (and a few variants) have been added. kvmalloc() will try to allocate memory with kmalloc(), but will fall back to vmalloc() if need be. These helpers have replaced a lot of duplicated fallback code elsewhere in the kernel.

  • The minitty TTY replacement was not merged, but a fair amount of preparatory work for minitty was included in the TTY pull for 4.12.

  • The PCI bus layer has gained support for controllers that can operate in endpoint mode. See Documentation/PCI/endpoint/pci-endpoint.txt for details.

  • The (relatively) new refcount_t reference-counting type was added in 4.11 and exported to GPL-compatible modules only. In 4.12 (and likely in forthcoming 4.11 stable updates) refcount_t will be changed to use EXPORT_SYMBOL() and, thus, will be accessible to all modules.

The merge window can be expected to close by May 14. At this point we have certainly seen the bulk of the changes that can be expected for this development cycle. A final update next week will cover any stragglers that show up in the final days of this merge window.

Index entries for this article
KernelReleases/4.12


to post comments

A couple suggestions

Posted May 11, 2017 0:14 UTC (Thu) by yodermk (guest, #3803) [Link] (2 responses)

I have a couple suggestions for the kernel merge window articles.

1) You've been publishing these on Wednesdays with your weekly edition; that splits it up into three articles -- the second covering a full week of merges but the first and third covering a half a week. The new LWN format lends itself to splitting it up into two equal sections (by time anyway), perhaps published on Monday morning.

2) All the new hardware support. I like it, but would like to see more. A list of the names of things supported means only a little. A bit more about these new things would be great. Can they do anything particularly interesting? Who would care about them -- desktop/laptop/phone users, datacenter managers, single-board computer tinkerers?

Thanks!

A couple suggestions

Posted May 11, 2017 14:02 UTC (Thu) by corbet (editor, #1) [Link]

We have pondered adjusting the timing of these articles. For this cycle, we decided to keep the edition timing, but that might well change in the future.

The other suggestion is rather harder to act upon. It's quite a bit of work just to come up with the list of newly supported hardware; driver authors, for whatever reason, often do not go out of their way to make that obvious. Trying to document why somebody might be interested in a new pulse-width modulator controller would expand that work considerably. For the most part, the drivers are of interest to somebody who has a computer with that specific device and wants it to work...

A couple suggestions

Posted May 12, 2017 0:38 UTC (Fri) by fratti (guest, #105722) [Link]

>A bit more about these new things would be great. Can they do anything particularly interesting?

You can read the data sheets for that. Figuring out what each chip brings to the table would require the author to have knowledge of the entire field these chips are used in. A lot of these drivers are for embedded use cases, so the one who cares about the drivers the most are the hardware vendors and the people building products based on the chips.

4.12 Merge window part 2

Posted May 11, 2017 16:36 UTC (Thu) by nevets (subscriber, #11875) [Link] (1 responses)

> The new "function-fork" tracing option will, when trace events are limited to a specific set of processes, cause any new child processes to be added to the set.

I should elaborate on this more. This option actually has nothing to do with trace events. It has to do with function tracing. Trace events use the event-fork option, which adds children into the set_event_pid file. This was added in 4.7.

The function-fork option does the same for set_ftrace_pid. When a task with a pid in that file forks, its child will be added to the file too, if the option is set. Then the function tracer will also trace the child process.

4.12 Merge window part 2

Posted May 12, 2017 20:10 UTC (Fri) by xtifr (guest, #143) [Link]

Ah, cool, thanks for the elaboration. It's appreciated.


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