3.18 Merge window part 2
Some 5,786 changes have been merged since last week's summary. The more interesting user-visible changes include:
- The bpf() system call is now
in the mainline.
The hooks to use this code (in tracing and packet filtering,
for example) will take a little longer, but the core support for a
"universal virtual machine" in the kernel is now present.
- The networking performance improvements described in this article have been merged. Among
other things, they allow a relatively small system to drive a
high-speed interface at full wire speed, even when small packets are
being transmitted. Small-packet performance has been a problem area
for Linux, so this is an important improvement.
- The Foo-over-UDP subsystem has been
merged; it provides support for tunneling protocols via UDP.
- The Data Center TCP (DCTCP) congestion control algorithm is now
supported. See the
commit message for a lot of information and this
page for even more.
- The Generic Network Virtualization Encapsulation (Geneve) protocol is
now supported; see this page
for more information.
- The fanotify_init() system call has, as the result of a bug,
always ignored the O_CLOEXEC option (which requests that the
resulting file descriptor be closed should the program call
exec()). As of 3.18, that bug has been fixed. There have
been some concerns that applications might silently depend on this
option not being honored; developers working with the fanotify
interface will thus want to pay attention to this change.
- The prctl() system call supports a new PR_SET_MM_MAP
operation to set the core parameters of a process's address space
layout: where the code and data areas are, the break pointer, where
the stack is, etc. See the
commit changelog for details on how this interface works.
- The new Xen "pvSCSI" subsystem allows Xen guests to drive SCSI devices
that have been assigned to them.
- The SPARC64 architecture now uses four-level page tables, vastly
increasing the amount of memory that can be addressed.
- The Smack mandatory access control subsystem has a new "bring-up" mode
that can be used to record the permissions a process needs to
execute. It is intended to be used in the writing of Smack rules,
then compiled out on production systems.
- As usual, the list of features added to the perf events subsystem and
the user-space perf tool is long; see this
commit message for details.
- New hardware support includes:
- Systems and processors:
Hisilicon HiP04 Cortex A15 systems-on-chip (SoCs),
Amlogic Meson6 (8726MX) SoCs,
Renesas R-Car E2 (R8A77940) SoCs,
Broadcom BCM63xx DSL SoCs,
Atmel SAMA5D4 SoCs, and
Cavium Inc. Thunder SoCs.
- Audio:
Cirrus Logic CS35L32 codecs,
Freescale generic sound cards,
Everest ES8328 audio codecs,
Freescale ES8328 audio codecs, and
Analog Devices SSM4567 audio amplifiers.
- Miscellaneous:
Atmel multi-port DDR SDRAM controllers,
Altera SDRAM memory controllers,
TI Keystone Navigator controllers,
TI Keystone PCIe controllers,
Allwinner A31 real-time clocks,
Texas Instruments Keystone 2 IRQ controllers,
APM X-Gene GPIO and PCIe controllers,
Xilinx AXI PCIe host bridges,
MEN 14F021P00 board management controllers,
IBM coherent accelerators,
Rockchip RK808 real-time clocks, and
Maxim 77802 real-time clocks.
- Networking:
Bosch M_CAN controllers,
Broadcom UniMAC MDIO bus controllers,
Broadcom Starfighter 2 Ethernet switches,
Intel FM10000 Ethernet switch host interfaces,
Marvell 88E6171 Ethernet switches, and
Qualcomm Atheros QCA7000 Ethernet controllers.
- Video4Linux: CIMaX SP2/SP2HF common interface modules, TechnoTrend TVStick CT2-4650 CI devices, HackRF software-defined radios, DVBSky USB receivers, Hisilicon hix5hd2 IR remote controls, MaxLinear MxL301RF tuners, Sharp QM1D1C0042 tuners, Toshiba TC90522 demodulators, and Earthsoft PT3 PCIe cards.
- Systems and processors:
Hisilicon HiP04 Cortex A15 systems-on-chip (SoCs),
Amlogic Meson6 (8726MX) SoCs,
Renesas R-Car E2 (R8A77940) SoCs,
Broadcom BCM63xx DSL SoCs,
Atmel SAMA5D4 SoCs, and
Cavium Inc. Thunder SoCs.
Changes visible to kernel developers include:
- The longstanding "vivi" test driver in the Video4Linux subsystem
has been replaced with a new driver called "vivid." This driver can
be used both as an example for how V4L drivers should be written and a
module for testing user-space programs.
- The RCU tasks subsystem has been merged; it allows RCU-like behavior
under a relaxed set of rules. See this
article for details.
- The device tree "resolver" is now available in the kernel. The resolver acts like a sort of linker, resolving references to device tree sections ("phandles") at load time. This work is part of a larger effort to implement run-time configurable device trees.
Stay tuned; next week will include a summary of the changes merged since
this article was written.
Index entries for this article | |
---|---|
Kernel | Releases/3.18 |
Posted Oct 22, 2014 6:29 UTC (Wed)
by dlang (guest, #313)
[Link] (4 responses)
This sort of approach to setting up complex permissions is a good one. It requires that there is a good test plan to exercise all the corner cases of the application, but you are doing that already, right? ;-)
Posted Oct 22, 2014 9:37 UTC (Wed)
by etienne (guest, #25256)
[Link] (3 responses)
> This sort of approach to setting up complex permissions is a good one. It requires that there is a good test plan to exercise all the corner cases of the application, but you are doing that already, right? ;-)
If the application is calling home to see if there is a newer version and decides to self-upgrade (not using the official upgrade system is bad (TM) but still done), then that application needs *a lot of* permissions.
Posted Oct 22, 2014 21:57 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
Posted Oct 22, 2014 23:16 UTC (Wed)
by dlang (guest, #313)
[Link] (1 responses)
But if you aren't wanting that to happen, don't allow it to happen during your test and if something slips in where it tries to do so in production, it will fail.
so this is still a good tool.
Posted Oct 23, 2014 9:20 UTC (Thu)
by etienne (guest, #25256)
[Link]
I do not want it! but some application do it anyway...
> But if you aren't wanting that to happen, don't allow it to happen during your test and if something slips in where it tries to do so in production, it will fail.
Usually only partly fail, partly succeed...
3.18 Merge window part 2
3.18 Merge window part 2
The worst is when the application self upgrade, but in the middle is refused write/creation access to a small file - and that upgrade finishes non-functional in subtle way, non reproduce-able on the developer machine.
Another requirement for package manager: an application shall be able to self-upgrade without needing root access? How about self-upgrading a library it is using? Only libraries written in an interpreted language (Python, java, ...) can be self-upgraded?
3.18 Merge window part 2
3.18 Merge window part 2
3.18 Merge window part 2