4.12 Merge window part 2
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 window4.0 8,950 4.1 10,659 4.2 12,092 4.3 10,756 4.4 11,528 4.5 10,305 4.6 12,172 4.7 10,707 4.8 11,618 4.9 14,304 4.10 11,455 4.11 10,960 4.12 11,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.
- 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.
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 | |
---|---|
Kernel | Releases/4.12 |
Posted May 11, 2017 0:14 UTC (Thu)
by yodermk (guest, #3803)
[Link] (2 responses)
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!
Posted May 11, 2017 14:02 UTC (Thu)
by corbet (editor, #1)
[Link]
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...
Posted May 12, 2017 0:38 UTC (Fri)
by fratti (guest, #105722)
[Link]
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.
Posted May 11, 2017 16:36 UTC (Thu)
by nevets (subscriber, #11875)
[Link] (1 responses)
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.
Posted May 12, 2017 20:10 UTC (Fri)
by xtifr (guest, #143)
[Link]
A couple suggestions
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.
A couple suggestions
A couple suggestions
4.12 Merge window part 2
4.12 Merge window part 2