3.9 Merge window, second episode
But first, a warning for development kernel testers: there are reports of ext4 filesystem corruption with current mainline kernels. The problem appears to have been identified and fixed, but it will remain as a permanent hazard for anybody running bisections over the 3.9 merge window. Development kernels have not often lived up to their fearsome reputation recently, but they can still bite at times.
- The ARM architecture has gained support for the KVM virtualization
mechanism on Cortex-A15 processors. Support for the ARM "power state
coordination interface" has been added so that virtual CPU's can be
"powered up" and down.
- The socket filtering mechanism has a new SO_LOCK_FILTER
option that prevents further changes to the filter. It is intended
for privileged programs that install a filter before running untrusted
code.
- TCP and UDP sockets have a new option, SO_REUSEPORT, that allows
multiple sockets listening for new connections or packets
(respectively) at the same time. See this
commit message for more information.
- The netfilter connection-tracking code now supports "connection
labels," which are bitmasks that can be attached to tracking entries and
tested by netfilter rules.
- The wireless networking subsystem has gained core support for the
detection of radar systems operating on the networking frequencies;
this is a necessary component for dynamic
frequency selection in the 5GHz range.
- VMware's "VM Sockets" subsystem, a mechanism for communication between
virtual machines and a hypervisor, has been merged. Also merged is
the "Virtual Machine Communication Interface" subsystem for high-speed
communication between the host and guests.
- The networking layer has support for the "Multiple VLAN Registration
Protocol" (MVRP), which facilitates communication about registered
virtual networks to switches.
- The block layer's handling of pages under writeback has been changed to address the
performance penalty imposed by the previous "stable pages" work.
- The PowerPC architecture supports a new set of transactional memory
instructions; at this time, only user-space support is provided (the
kernel does not use these instructions). See Documentation/powerpc/transactional_memory.txt
for more information.
- The Xen virtualization subsystem gained support for ACPI-based CPU and
memory hotplugging, though, in both cases, only the "add" operation is
supported currently.
- The ext4 filesystem now supports hole punching in block-mapped files.
- A long list of old network drivers has been deleted; these include the
venerable 3c501, 3c505, and 3c507 drivers, various Intel i825xx
drivers, parallel port-based drivers(!), and many more. It is
expected that these drivers will not be
missed, as many of them did not work all that well in the first
place. As Paul Gortmaker put
it: "
You know things are not good when the Kconfig help text suggests you make a cron job doing a ping every minute.
" The long-unused "WAN router" subsystem has also been removed. - New hardware support includes:
- Systems and processors:
NVIDIA Tegra114 SoCs,
the ARM "dummy virtual machine" (a minimal stub platform for
virtualization uses),
Prodrive PPA8548 AMC modules, and
Tensilica Diamond 233L Standard core Rev.C processors.
- Audio:
NVIDIA Tegra20 AC97 interfaces.
- Block:
Renesas R-Car SATA controllers and
Broadcom BCM2835 SD/MMC controllers.
- Graphics:
Marvell MMP display controllers,
Samsung LMS501KF03 LCD panels,
Himax HX-8357 LCD panels,
Austrian Microsystems AS3711 backlight controllers,
TI LCDC display controllers, and
NXP Semiconductors TDA998X HDMI encoders.
- Input:
Steelseries SRW-S1 steering wheel devices.
- Miscellaneous:
STMicroelectronics ST33 I2C TPM devices,
STMicroelectronics accelerometers, magnetometers, and gyroscopes,
InvenSense ITG3200 digital 3-axis gyroscopes,
Invensense MPU6050 gyroscope/accelerometer devices,
NVIDIA Tegra20/30 SoC serial controllers,
Comtrol RocketPort EXPRESS/INFINITY serial adapters,
PCI-Express non-transparent bridges,
Maxim MAX77686 and MAX8997 realtime clocks (RTCs),
TI LP8788 RTCs,
TI TPS80031/TPS80032 RTCs,
Epson RX-4581 RTCs,
ST-Ericsson Ux500 watchdogs,
Intel Lynxpoint GPIO controllers,
Atmel Timer Counter pulse-width modulators,
TI/National LP5521 and LP5523/55231 LED controllers,
Intel iSMT SMBus host controllers, and
Broadcom BCM2835 I2C controllers.
- Networking:
8devices USB2CAN interfaces and
Inside Secure microread NFC interfaces.
- USB:
SMSC USB3503 USB 2.0 hub controllers.
- Video4Linux:
SuperH VEU mem2mem video processors,
TI DM365 VPFE media controllers,
Montage Technology TS2020-based tuners,
Masterkit MA901 USB FM radios,
OmniVision OV9650/OV9652 sensors, and
Samsung S5C73M3 sensors.
- Staging graduations: the Analog Devices ADXRS450/3 Digital Output Gyroscope SPI driver, Analog Devices ADIS16400 inertial sensor driver, Analog Devices ADIS16080/100 yaw rate gyroscope driver, Kionix KXSD9 accelerometer driver, TAOS TSL2560, TSL2561, TSL2562 and TSL2563 ambient light sensor driver, and OMAP direct rendering driver have been moved out of the staging tree and into the mainline kernel.
- Systems and processors:
NVIDIA Tegra114 SoCs,
the ARM "dummy virtual machine" (a minimal stub platform for
virtualization uses),
Prodrive PPA8548 AMC modules, and
Tensilica Diamond 233L Standard core Rev.C processors.
Changes visible to kernel developers include:
- The netpoll mechanism now supports IPv6, allowing network consoles to
be run over IPv6 networks.
- Most drivers no longer depend on the EXPERIMENTAL
configuration option. So much code needed that option that it is
turned on almost universally, with the result that it does not
actually mean anything. So now it defaults to "yes," and it will soon
be removed entirely.
- The sound layer has a generic parser for Intel high definition audio
(HDA) codecs. Many drivers have been converted to use this parser,
resulting in the removal of a great deal of duplicated code.
- The __get_user_8() function is now available on 32-bit x86
systems; it will fetch a 64-bit quantity from user space.
- The module signing code has a few usability enhancements. The
sign-file utility has new options to specify which hash
algorithm to use or to simply provide the entire signature (which will
have been computed elsewhere). There is also a new
MODULE_SIG_ALL configuration option that controls whether
modules are automatically signed at modules_install time.
- The descriptor-based GPIO patch set
has been merged, with significant changes to how GPIO lines are
handled within the kernel.
- The new file_inode() helper should be used instead of the traditional file->f_dentry->d_inode pointer chain.
The merge window should stay open through approximately March 5, though,
one assumes, the rate of change will drop off somewhat toward the end.
Next week's edition will summarize the changes that go in for the final
part of the 3.9 merge window.
| Index entries for this article | |
|---|---|
| Kernel | Releases/3.9 |
Posted Feb 28, 2013 15:22 UTC (Thu)
by tytso (subscriber, #9993)
[Link] (1 responses)
That being said, I'm very embarrassed this bug slipped through our code review and testing processes. We have been discussing how to improve the testing that we do on ext4 file systems to avoid this sort of problem from slipping through our development cycle in the future.
Posted Feb 28, 2013 16:27 UTC (Thu)
by jimparis (guest, #38647)
[Link]
Posted Feb 28, 2013 19:37 UTC (Thu)
by nix (subscriber, #2304)
[Link] (3 responses)
[...]
One bug on the chip is that even a hard reset won't disable the memory
window, usually resulting in a hung machine if mem_off() isn't called.
If this happens, you must power down the machine for about 30 seconds.
send and receive about 350-400 KByte/s (peak up to 460 kbytes/s)
sending in NOP-mode: peak performance up to 530K/s (but better don't
run this mode)
Posted Mar 1, 2013 0:21 UTC (Fri)
by dashesy (guest, #74652)
[Link] (1 responses)
Posted Mar 1, 2013 18:06 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Mar 16, 2013 12:38 UTC (Sat)
by makomk (guest, #51493)
[Link]
"For the avoidance of doubt the "preferred form" of this code is one which is in an open non patent encumbered format. Where cryptographic key signing forms part of the process of creating an executable the information including keys needed to generate an equivalently functional executable are deemed to be part of the source code."
Apparently stuff like tivoization and Secure Boot were foreseen some time ago...
Posted Mar 1, 2013 0:36 UTC (Fri)
by dashesy (guest, #74652)
[Link]
3.9 Merge window, second episode
3.9 Merge window, second episode
In addition to a number of DEC copyrights and a bunch of Don Becker's drivers, a number of fabulous comments have disappeared from the kernel this day. A selection:
3.9 Merge window, second episode
*!@$ protocol=eth_type_trans -- now packets flow
The EtherWORKS 3 driver in this distribution is designed to work with all
kernels > 1.1.33 (approx) and includes tools in the 'ewrk3tools'
subdirectory to allow set up of the card, similar to the MSDOS
'NICSETUP.EXE' tools provided on the DOS drivers disk (type 'make' in that
subdirectory to make the tools).
2) if you wish, edit the source code near line 1530 to reflect the I/O
address and IRQ you're using
Fix the last fix...sorry, must be galloping senility
case DEPCA_SAY_BOO: /* Say "Boo!" to the kernel log file */
if(!capable(CAP_NET_ADMIN))
return -EPERM;
printk("%s: Boo!\n", dev->name);
break;
/* This should be probed for (or set via an ioctl()) at run-time.
Right now we use a sleazy hack to pass in the interface number
at boot-time via the low bits of the mem_end field. That value is
unused, and the low bits would be discarded even if it was used. */
[This is currently quite safe.... but if one day the 3c503 explodes
you know where to come looking ;)]
The E2100 series ethercard is a fairly generic shared memory 8390
implementation. The only unusual aspect is the way the shared memory
registers are set: first you do an inb() in what is normally the
station address region, and the low three bits of next outb() *address*
is used as the write value for that register. Either someone wasn't
too used to dem bit en bites, or they were trying to obfuscate the
programming interface.
The MB86965 has a design flaw that makes all probes unreliable. Not
only is it difficult to detect, it also moves around in I/O space in
response to inb()s from other device probes!
results from ftp performance tests with Linux 1.2.5
The card has 256k of on-board RAM, which is used to buffer received packets. It
might seem at first that more buffers are better, but in fact this isn't true.
From my tests, it seems that more than about 10 buffers are unnecessary, and
there is a noticeable performance hit in having more active on the card. So
the majority of the card's memory isn't, in fact, used.
And, of course, the immortal 3c501:
Do not purchase this card, even as a joke. It's performance is horrible,
and it breaks in many ways.
Some documentation is available from 3Com. Due to the boards age
standard responses when you ask for this will range from 'be serious'
to 'give it to a museum'. The documentation is incomplete and mostly
of historical interest anyway.
The driver is less efficient than it could be. It switches through
receive mode even if more transmits are queued. If this worries you buy
a real Ethernet card.
Attempt to send a packet to a 3c501 card. There are some interesting
catches here because the 3c501 is an extremely old and therefore
stupid piece of technology.
We have a good packet. Well, not really "good", just mostly not broken.
3.9 Merge window, second episode
3.9 Merge window, second episode
3.9 Merge window, second episode
3.9 Merge window, second episode