|
|
Subscribe / Log in / New account

4.3 Merge window, part 1

By Jonathan Corbet
September 2, 2015
As of this writing, just over 4,000 non-merge changesets have been pulled into the mainline kernel repository for the 4.3 development cycle. This merge window, in other words, is just getting started. But that is enough to begin to show the shape of this development cycle: useful incremental changes, but not much, thus far, in the way of high-profile features.

The user-visible changes merged so far include:

  • The kernel now supports the attachment of BPF programs to uprobes, making more flexible tracing of user-space code possible. There is also a new libbpf library that is meant to ease the process of working with BPF scripts; its first user is the perf tool.

  • There is a new "PIDs" controller for the control-group subsystem; it enforces a limit on the number of processes contained within the group. This controller thus serves as a sort of defense against fork bombs and similar attacks. See Documentation/cgroups/pids.txt for details.

  • The perf tool has gained the ability to work with Intel processor trace streams.

  • The s390 architecture has gained "fake NUMA" support. This allows a large system to be configured into a set of emulated NUMA nodes, making it easier to partition workloads and, in some situations, improving performance.

  • The CONFIG_VM86 option provides access to the 16-bit legacy mode on x86 systems. Its use has been in decline for years, there are no known recently released tools that need it, and it has been recently shown to have a number of unpleasant problems, some of which are security-related. In 4.3, this option will be renamed (to CONFIG_X86_LEGACY_VM86) and disabled by default. Hopefully nobody actually needs the VM86 mode and it can be removed entirely in the near future.

  • New hardware support includes:

    • Industrial I/O: ROHM RPR0521 ambient-light and proximity sensors, Texas Instruments OPT3001 light sensors, and TXC PA12203001 light and proximity sensors.

    • Miscellaneous: Qualcomm coincell battery chargers, Qualcomm SMD based RPM regulators, UltraChip UC1611 LCD controllers, MediaTek MT6311 power-management ICs, MediaTek SPI controllers, MediaTek SCPSYS power domain controllers, Mediatek MT8173 CPU-frequency controllers, Netlogic XLP SPI controllers, Allwinner Security System cryptographic accelerators, Intel DH895xCC crypto accelerators, ARM PrimeCell PL172 multiport memory controllers, and NVIDIA Tegra124 CPU-frequency controllers.

    • MOST: The MOST specification is a standard for media networking aimed at the automotive industry. The 4.3 kernel will include (in the staging tree) a new MOST subsystem with support for network, sound, media drivers and more. See this document for some introductory information.

    • USB: Qualcomm APQ8016/MSM8916 USB transceiver controllers, Allwinner sun4i A10 musb DRC/OTG controllers, and NXP LPC18xx/43xx SoC USB OTG PHYs.

Changes visible to kernel developers include:

  • There is a new driver framework for nonvolatile memory devices (EEPROMs and the like); see Documentation/nvmem/nvmem.txt for some details.

  • DocBook comments for structures can now be split into multiple chunks within the structure, easing the process of documenting the fields of especially large structures. The HTML document generator can also now create internal cross-reference links automatically.

One pull request that has not yet been acted upon by Linus is Jan Kara's request deleting the ext3 filesystem, as was covered here in July. Linus is worried that the change will force ext3 users to upgrade their filesystems in non-backward-compatible ways, but, as Ted Ts'o explained, that should not happen. Your editor would hazard a guess that this removal will go through before the merge window closes.

If the normal schedule holds, that closure should happen on September 13. As usual, LWN will follow the commit stream and call out the most interesting changes as they happen.

Index entries for this article
KernelReleases/4.3


to post comments

CONFIG_VM86

Posted Sep 3, 2015 10:39 UTC (Thu) by epa (subscriber, #39769) [Link] (5 responses)

Sad news that V86 mode is on the way out. I remember the excitement of getting MS-DOS (or FreeDOS) running under dosemu on Linux, with almost the full native CPU speed available to the DOS virtual machine. More so if you then enabled direct video access in the dosemu config, so that DOS games would work, at the risk of crashing the machine if you configured it wrong...

But nowadays CPUs are so much faster than they were even in the last days of DOS (mid 1990s or so) that you can use a software emulator such as Bochs and it's easily fast enough. Also, V86 mode is not accessible from 64-bit mode on x86_64 processors anyway.

- What about Wine running 16-bit Windows applications? Does that use V86 mode? The old 'real mode' (8086) Windows applications (like winword 1.x) are impossibly ancient but I wouldn't be surprised to see some 'standard mode' (80286) programs still in use in the corporate world. They won't run on 64-bit Windows but I think 32-bit Windows still supports them.

CONFIG_VM86

Posted Sep 3, 2015 16:54 UTC (Thu) by drv (subscriber, #78370) [Link] (1 responses)

The new config option help text (CONFIG_X86_LEGACY_VM86) contains this sentence:
"This option is also unrelated to 16-bit protected mode and is not needed to run most 16-bit programs under Wine."

I haven't tested this myself, but I hope it's true.

CONFIG_VM86

Posted Sep 6, 2015 21:22 UTC (Sun) by mstefani (guest, #31644) [Link]

That's correct, Wine doesn't needs that for Win16 programs.
Should your application bundle DOS binaries then install DOSBox and Wine will use that. Wine will automatically configure DOSBox to use the same drive setup as under Wine.

CONFIG_VM86

Posted Sep 3, 2015 17:45 UTC (Thu) by corbet (editor, #1) [Link]

It's looking like the VM86 semi-removal may have been premature, and that more stuff needs it than was expected...stay tuned...

CONFIG_VM86

Posted Sep 3, 2015 18:59 UTC (Thu) by malor (guest, #2973) [Link] (1 responses)

On AMD processors, you can apparently run 16-bit code in native mode through their hardware virtualization. Intel can't, they've dropped 16-bit code completely in 64-bit mode, but you could probably get full speed MS-DOS on a 64-bit AMD processor if you virtualized it.

I/O will still be slow, of course, but probably faster than it would have been on a real DOS machine, and the CPU should be extremely fast, by those old standards.

I haven't actually tried it, as I don't have any AMD processors, but it sounds like it would work.

CONFIG_VM86

Posted Oct 28, 2015 23:15 UTC (Wed) by josh (subscriber, #17465) [Link]

> On AMD processors, you can apparently run 16-bit code in native mode through their hardware virtualization. Intel can't, they've dropped 16-bit code completely in 64-bit mode

No, you can run 16-bit code on Intel VT in all processors since Westmere; the feature is called "unrestricted mode", which also allows running in protected mode without paging enabled.

4.3 Merge window, part 1

Posted Sep 3, 2015 17:14 UTC (Thu) by RobSeace (subscriber, #4435) [Link] (1 responses)

> uprobes

*blink* Ah, u-probes... I was reading it as up-robes, and picturing something akin to up-skirt, and was very confused...

4.3 Merge window, part 1

Posted Sep 3, 2015 18:30 UTC (Thu) by bronson (subscriber, #4806) [Link]

Oh great. I was previously reading it as u-probes just fine, now I can't stop seeing up-robes. Hope this effect wears off.

4.3 Merge window, part 1

Posted Sep 4, 2015 0:19 UTC (Fri) by gdt (subscriber, #6284) [Link]

Not sure the NVMEM API allows for removable EEPROMs, notably those in SFPs.


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