3.17 merge window part 1
- The perf tool can now perform page fault tracing and generate
associated statistics. Additionally, "perf timechart" can
generate charts displaying I/O events.
- Four-level page tables have been added to the arm64 architecture,
greatly expanding the amount of virtual memory that can be addressed.
This feature will likely not be enabled in 3.17 kernels, though, due
to the need for more work. The arm64 architecture has also gained
audit support.
- The cryptographic subsystem has gained support for the NIST-specified
SP800-90A deterministic random bit generator. There is also support
for parsing PKCS#7 signed-data messages and verifying the signatures.
- The netfilter "ulog" target, long deprecated, has finally been
removed. The "NFLOG" target should be used instead.
- Cross-thread filter setting for the
secure computing ("seccomp") facility has been added. The interface
has changed over time, though; there is now a new system call for
seccomp:
int seccomp(unsigned int operation, unsigned int flag, const char *args);
This man page describes the new system call and the available commands. - The security module subsystem has gained a new hook
(kernel_fw_from_file()) that may be used to verify the
integrity of firmware blobs before accepting them in the kernel.
- The getrandom() system call
has been merged.
- New hardware support includes:
- Block: NVIDIA Tegra124 AHCI SATA controllers,
Qualcomm APQ8064 and IPQ806x SATA SerDes/PHY controllers,
Marvell Berlin SATA PHY controllers, and
STMicroelectronics MIPHY365X SATA PHY controllers.
- Clock:
TI Palmas clk32kg and clk32kgaudio clocks,
Rockchip rk3188, rk3066, and rk3288 clocks,
Qualcomm APQ8084 clock controllers, and
Cirrus Logic CLPS711X clocks.
- Hardware monitoring:
Lattice POWR1220AT8 power-management ICs,
Texas Instruments TMP103 temperature sensors,
Texas Instruments TPS40422 power management chips,
IBM POWERNV platform sensors, and
PWM-connected fans.
- IIO:
EPCOS T5403 digital barometric pressure sensors,
Kionix KXCJK-1013 triaxial acceleration sensors,
Asahi Kasei AK09911 3-axis compasses,
Microchip MCP4902, MCP4912, and MCP4922 digital-to-analog converters,
Maxim max1027, max1029 and max1031 analog-to-digital converters,
Intersil ISL29125 digital color light sensors,
TAOS TCS3414 digital color sensors, and
Honeywell HMC5983 3-Axis magnetometers.
- Miscellaneous: Intel E3-1200 DRAM controllers,
Intel DH895xcc crypto accelerators (and Intel "Quick Assist
Technology" devices in general),
Intel MIC X100 DMA controllers,
Qualcomm crypto engine accelerators,
Thunderbolt devices on Apple systems,
Maxim DS2406 addressable switches,
Rockchip SPI controllers,
Dialog Semiconductor DA9211/DA9212 regulators, and
Atmel AT91 interrupt controllers.
- Networking:
TI CC2520 802.15.4 wireless-PAN networking controllers,
Marvell Armada 375 Ethernet controllers, and
STMicroelectronics ST21NFCB NFC controllers.
- USB:
Silicon Mitus SM5502 USB port switches,
Emma Mobile EMXX USB function device controllers,
Renesas R-Car xHCI host controllers, and
NetChip PLX USB3380 and USB3382 USB peripheral controllers.
- Video4Linux: Allwinner sunXi IR controllers, AirSpy software-defined radio controllers, Silicon Labs SI2165 DVB-C/-T demodulators, and Samsung Exynos3250 JPEG codecs.
It's worth noting that 14 unloved drivers were removed from the staging tree, eliminating some 250,000 lines of code. Indeed, as of this writing, 3.17 is actually smaller than 3.16. A kernel release has been smaller than its predecessor only one other time in kernel development history (2.6.36).
- Block: NVIDIA Tegra124 AHCI SATA controllers,
Qualcomm APQ8064 and IPQ806x SATA SerDes/PHY controllers,
Marvell Berlin SATA PHY controllers, and
STMicroelectronics MIPHY365X SATA PHY controllers.
Changes visible to kernel developers include:
- A number of changes have been made to the timekeeping core in order
to make it ready for the year 2038; see this article for details.
- The dma-buf fence API has been added.
This subsystem enables cross-device synchronization and coordination,
especially around the use of DMA buffers. In the end, this API was
made available to all kernel modules; a
push to change it to the
EXPORT_SYMBOL_GPL() mechanism was not successful.
- The "config-bisect" mode in the ktest utility has been
reworked to be much smarter about finding the actual configuration
change that causes problems.
- The ftrace subsystem has been reworked to make things more efficient
when multiple tracers are active, and, in particular, when function
graph tracing is being performed.
- Arm64 kernels can now be built with the -fstack-protector
option to detect stack corruption.
- The wait_on_bit() function (along with its variants) has been reworked to no longer require an "action" function since, as it turned out, most of those functions were duplicates of each other.
In the 3.16 announcement, Linus noted that
he will be traveling during the latter part of the 3.17 merge window. That
may, he said, cause this merge window to be a little longer than usual.
Subsystem maintainers would be wise to not count on that when sending their
pull requests, though. It seems likely that Linus will feel motivated to
close the merge window and get the 3.17-rc1 release out before the Kernel
Summit starts on August 18.
Index entries for this article | |
---|---|
Kernel | Releases/3.17 |
Posted Aug 7, 2014 7:06 UTC (Thu)
by jzbiciak (guest, #5246)
[Link] (3 responses)
Posted Aug 9, 2014 14:15 UTC (Sat)
by pr1268 (subscriber, #24648)
[Link] (2 responses)
Hehe, I had to think about that one for a moment. Seems I have difficulty recognizing 3 ✕ 2n. (Perhaps that's why I was hell-bent on buying a new laptop with 8GB of RAM instead of 6GB.) :-) P.S. (and going off on a tangent): Anyone remember Bill Gates' non-quote "640K ought to be enough for anybody"? That's 5 ✕ 2n (for n = 17). A PC with five SIMM slots (or whatever the onboard memory expansion slots were called back then) would be interesting...
Posted Aug 9, 2014 15:03 UTC (Sat)
by jzbiciak (guest, #5246)
[Link] (1 responses)
IIRC, on the PC XT, it was actually 4 rows of 9 DIPs (36 discrete chips, including parity). 2 rows of 256Kx1 chips, and 2 rows of 64Kx1 chips, as I recall. Some were socketed and some were soldered in. Why not three rows of 256Kx1? Not sure. If I had to venture a guess, it was probably due to the memory map they established with the original IBM PC. The MDA and CGA adaptors started at B:0000 and B:8000, which prevents you from going to 768K of contiguous memory without moving them and breaking compatibility with the original 5150. Given that the 5150 came with only 16K or 64K of RAM originally, I guess it wasn't a pressing concern at the time? I don't miss the 640K era.
Posted Aug 9, 2014 17:10 UTC (Sat)
by dlang (guest, #313)
[Link]
exactly, it wasn't until the memory got cheap enough in larger sizes that manufacturers started installing 1M of RAM on the boards even though the system could only use 640K (because it was cheaper for them to do so then to deal with two sizes of chips) that high memory was born.
and when the XT was shipped (at a price of ~$5K IIRC with two floppies and 16K of RAM, imagining that 640K would be limiting was hard.
I don't miss those days either.
Posted Aug 7, 2014 8:51 UTC (Thu)
by bokr (subscriber, #58369)
[Link]
(Comment rationale: not "in the article" per se ;-)
Posted Aug 7, 2014 9:39 UTC (Thu)
by Thue (guest, #14277)
[Link] (1 responses)
> The cryptographic subsystem has gained support for the NIST-specified SP800-90A deterministic random bit generator.
Yes - finally we get Dual_EC_DRBG in the kernel!
Posted Aug 7, 2014 10:27 UTC (Thu)
by intgr (subscriber, #39733)
[Link]
See https://git.kernel.org/cgit/linux/kernel/git/torvalds/lin...
Posted Aug 12, 2014 19:44 UTC (Tue)
by mlankhorst (subscriber, #52260)
[Link] (4 responses)
Hooray!
Posted Aug 14, 2014 23:42 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (3 responses)
Because, at the end of the day, that fuss was all about peoples A telling peoples B how peoples B should licence their own code. And in the Open/Free Source communities, we just don't do that ...
If I want my code to be freely available and I have no intention whatsoever of suing over it, then it's damn stupid for my interface to be exported EXPORT_SYMBOL_GPL (because nobody else can sue over it, and I'm not going to ...)
Cheers,
Posted Aug 15, 2014 1:08 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Posted Aug 15, 2014 19:57 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
But they would be suing over THEIR work.
If my primary licence is BSD, then I can put my code in the kernel because it's GPL-compatible.
But it's damn stupid me marking MY modules as EXPORT_SYMBOL_GPL because I can't sue because it's BSD.
If someone else wants to licence and mark their code EXPORT_SYMBOL_GPL then good luck to them. That's their choice, just don't expect me to take that attitude over mine.
Cheers,
Posted Aug 15, 2014 20:02 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link]
Exactly 6K? (Or 6Ki for those who prefer the kibbles and bits prefixes... ;-) )
"some 6,144 non-merge changesets"
6,144
Exactly 6K? (Or 6Ki for those who prefer the kibbles and bits prefixes... ;-) )
6,144
That's 5 ✕ 2n (for n = 17). A PC with five SIMM slots (or whatever the onboard memory expansion slots were called back then) would be interesting...
6,144
3.17 merge window part 1
3.17 merge window part 1
3.17 merge window part 1
> All three viable DRBGs defined in the standard are implemented:
> * HMAC: This is the leanest DRBG and compiled per default
> * Hash: The more complex DRBG can be enabled at compile time
> * CTR: The most complex DRBG can also be enabled at compile time
3.17 merge window part 1
3.17 merge window part 1
Wol
3.17 merge window part 1
3.17 merge window part 1
Wol
3.17 merge window part 1