Linux 3.3 rilasciato con il merge di Android

1.1. Android merge

Recommended LWN article: Bringing Android closer to the mainline

For a long time, code from the Android project
has not been merged back to the Linux repositories due to disagreement
between developers from both projects. Fortunately, after several years
the differences are being ironed out. Various Android subsystems and
features have already been merged, and more will follow in the future.
This will make things easier for everybody, including the Android mod
community, or Linux distros that want to support Android programs.

Code: (commit), (commit), (commit), (commit)

1.2. Btrfs: restriping between different RAID levels, improved balancing, improved debugging tools

Improved balancing, raid restripping

In Btrfs, a “balance” operation consists in a
complete rewrite of the filesystem data, pushing all the rewritten data
and metadata through the allocators. This operation is needed in some
cases. For example if a new drive is added, a balance operation will be
needed to redistribute data to the new drive. This balance operation,
however, rebalanced the entire filesystem, which could take many hours,
and it didn’t support a change of raid profile.

The balancing implementation has been completely
reworked. Btrfs can now pause and resume a balance operation, and give
status updates. It is also possible to restripe between different raid
levels. It also lets filter the balance based on metadata/data profiles,
and lets balance only mostly empty block groups. The userspace utils
are available in the “parser” branch of the btrfs-progs.

Code: (commit 1 ,2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20)

Improved debugging

Btrfs has a new debugging utility, “integrity
check”, aimed at developers. The tool consist in a extra integrity test
that for every write request checks that the filesystem is not writting
to the disk bogus references that could left the file system in an
inconsistent state that would cause data loss. This tool will help Btrfs
developers to find bugs more easily.

Code: (commit 1, 2, 3)

1.3. Open vSwitch

Recommended LWN article: Routing Open vSwitch into the mainline

Open vSwitch is a software implementation of a
multilayer network switch. This project has existed for years and it’s
now being merged in the main tree. Linux already has a virtual switch
(the Linux bridge), but Open vSwitch is designed for more complex
scenearios, and specially to be used as a vswitch in virtualized server
environments (read the document “Why Open vSwitch?”

Open vSwitch supports standard management
interfaces (e.g. sFlow, Netflow, RSPAN, CLI), and is open to
programmatic extension and control using Openflow and the OVSDB
management protocol, and it is designed to be compatible with modern
switching chipsets. See openvswitch.org for more information and userspace utilities.

Code: (commit)

1.4. Better bonding of network interfaces: teaming

There is a new “teaming”
network device, which is intended to be a fast, scalable, clean,
userspace-driven replacement for the bonding driver. It allows to create
virtual interfaces that teams together multiple ethernet devices. This
is typically used to increase the maximum bandwidth and provide
redundancy. Currently round-robin and active-backup modes are
implemented. The libteam userspace library with couple of demo apps is
available at github.com/jpirko/libteam

Code: (commit)

1.5. Bufferbloat fighting: Byte queue limits

Recommended LWN article: Network transmit queue limits

“Bufferbloat”
is a term used to describe the latency and throughput problems caused
by excessive buffering trough the several elements of a network
connection. Some tools are being developed to help to alleviate these
problems, and this feature is one of them.

Byte queue limits are a configurable limit of
packet data that can be put in the transmission queue of a network
device. As a result one can tune things such that high priority packets
get serviced with a reasonable amount of latency whilst not subjecting
the hardware queue to emptying when data is available to send.
Configuration of the queue limits is in the tx-<n> sysfs directory
for the queue under the byte_queue_limits directory.

Code: (commit 1, 2, 3, 4, 5)

1.6. Per-cgroup TCP buffer limits

Recommended LWN article: Per-cgroup TCP buffer limits

This patch introduces memory pressure controls
for the tcp protocol which allows to put limits to the size of the
buffers used by the TCP code.

Code: (commit 1, 2, 3, 4, 5, 6, 7, 8)

1.7. Network priority control group

The Network priority cgroup
provides an interface to allow an administrator to dynamically set the
priority of network traffic generated by various applications.
Nominally, an application would set the priority of its traffic via the
SO_PRIORITY socket option. This however, is not always possible. This
cgroup allows an administrator to assign a process to a group which
defines the priority of egress traffic on a given interface. More
details in Documentation/cgroups/net_prio.txt

Code: (commit 1, 2)

1.8. Better Ext4 online resizing

This release supports a new
online resizing ioctl. The new resizing lets kernel do all work, like
allocating bitmaps and inode tables, it can support flex_bg and
BLOCK_UNINIT features and it’s much faster.

Code: (commit)

1.9. New architecture: TI C6X

Recommended LWN article: Upcoming DSP architectures

The family of architectures that run on Linux has
got even bigger with the addition of support for the Texas Instruments
C6X. This architecture supports members of the Texas Instruments family
of C64x single and multicore DSPs. The multicore DSPs do not support
cache coherancy, so are not suitable for SMP. Also, these are no-mmu
processors. This core architecture is VLIW with an instruction set
optimized for DSP applications. For details on the processors, see the TI web page. Also, the project website: linux-c6x.org

Code: (directory)

1.10. EFI boot support

This release introduces an
EFI boot stub that allows an x86 bzImage to be loaded and executed
directly by EFI firmware. The bzImage appears to the firmware as an EFI
application. Both BIOS and EFI boot loaders can still load and run the
same bzImage, thereby allowing a single kernel image to work in any boot
environment.

Code: (commit)