|
|
Subscribe / Log in / New account

Looking forward to 2.6.16

As of this writing, well over 2000 patches have been merged for the upcoming 2.6.16 kernel. The following list covers some of the more important or user-visible patches; it is not exhaustive by any means. Links to LWN articles describing the patches have been provided where available.

The 2.6.16 merge window will remain open for some time yet, so expect some more big changes before it is done.

User-visible changes

  • OCFS2, Oracle's clustered filesystem.

  • Networking changes include per-packet access control tied into the IPSec subsystem, an implementation of the "CUBIC" congestion control algorithm for TCP, an initial implementation of the DCCP protocol over IPv6, and a sysfs interface to the network bonding module, allowing runtime reconfiguration without the need to reload the module. There is also an obscure "intermediate functional block" network device option which can be used for configuration flexibility and resource sharing.

  • Module versioning (storing version information to help binary modules work with more than one kernel release) is no longer considered experimental.

  • The hotplug helper /sbin/hotplug is now officially deprecated. The control file /proc/sys/kernel/hotplug has moved to /sys/kernel/uevent_helper, but it is expected to be disabled on most systems in favor of udev and the netlink interface.

  • Copy-on-write support and NUMA awareness for "hugetlb" pages.

  • The software suspend code has seen some work. The encryption option has been removed; it was little used and offered little protection in the first place. A few steps have been taken toward moving parts of the suspend process to user space.

  • The swap migration code, allowing a process's pages to follow it from one processor to another. As of this writing, the direct migration patches have not been merged.

  • The "SLOB allocator" has been added; it is a replacement for the Linux slab code which is suited for very small-memory systems.

  • The oldest supported version of gcc for kernel building is now 3.2.

  • The ext3 filesystem has a new mount option allowing the location of the journal device to be specified.

  • The module loader now explicitly checks for the ndiswrapper and driverloader modules, and will mark the kernel tainted if they are found.

  • V9fs (the Plan9 filesystem) is now capable of performing zero-copy operations. Various other v9fs improvements have been added as well.

  • Support for the Cell architecture has been significantly filled out.

  • New drivers for ADI Eagle-based USB ADSL modems, ATI and Phillips USB remote control units, the Marvel Yukon2 Ethernet chipset, the network interface in the Intel ixp2000 (ARM) CPU, the CS5535 audio device, Digigram PCXHR boards, and the SyncLink GT and AC serial adaptor families.

Internal API changes

  • Ingo Molnar's mutex code has been added. A few patches converting subsystems over to mutexes have gone in, but most of that work remains to be done.

  • The usb_driver structure has a new field (no_dynamic_id) which lets a driver disable the addition of dynamic device IDs. The owner field has also been removed from this structure.

  • Some significant changes to the SCSI subsystem aimed at eliminating the use of the old scsi_request structure. The SCSI software IRQ is no longer used; postprocessing happens via the generic block software IRQ instead.

  • Vast numbers of typedefs have been removed from the ALSA code, bringing that subsystem more in line with kernel coding standards. Power management support has also been added to a number of ALSA drivers.

  • A new workqueue function schedule_on_each_cpu() will cause a function to be called on every running processor on the system.

  • Much of the core device model code has been reeducated to use the term "uevent" instead of "hotplug." Some changes which are visible outside of the core code include:
    • kobject_hotplug() becomes kobject_uevent()
    • struct kset_hotplug_ops becomes struct kset_uevent_ops, and its hotplug() member is now uevent()
    • add_hotplug_env_var() becomes add_uevent_var()

  • A 64-bit atomic type, atomic_long_t, has been added. Supported functions are:
    • long atomic_long_read(atomic_long_t *l);
    • void atomic_long_set(atomic_long_t *l, long i);
    • void atomic_long_inc(atomic_long_t *l);
    • void atomic_long_dec(atomic_long_t *l);
    • void atomic_long_add(long i, atomic_long_t *l);
    • void atomic_long_sub(long i, atomic_long_t *l);

  • The block I/O barrier code has been rewritten. This patch changes the barrier API and also adds a new parameter to end_that_request_last().

  • The block_device_operations structure has a new method getgeo(); its job is to fill in an hd_geometry structure with information about the drive. With this operation in place, many block drivers will not need an ioctl() function at all.

  • The dentry structure has been changed: the d_child and d_rcu fields are now overlaid in a union. This change shrinks this heavily-used structure and improves its cache behavior.

  • struct page has also been changed; it is now smaller on large SMP systems.

  • Linas Vepstas's PCI error recovery patch has been merged.

  • A new list function, list_for_each_entry_safe_reverse(), does just what one would expect.

  • The high-resolution kernel timer code has been merged. Much of the core works as described in this LWN article, but there have also been changes and most of the names are different. The new high-resolution timer interface will be discussed in the January 19 Kernel Page.

  • Buffering for the TTY layer has been completely redone.

As noted above, more changes are likely; stay tuned. Remember that API changes will eventually find their way onto the LWN 2.6 API Changes Page.


to post comments

NFS client updates

Posted Jan 10, 2006 22:47 UTC (Tue) by brugolsky (guest, #28) [Link] (4 responses)

Lots of NFS goodness also merged, as detailed in NFS Client Updates Against 2.6.15 Available including:
  • NFS: Make stat() return updated mtimes after a write()
    The SuS states that a call to write() will cause mtime to be updated on the file. In order to satisfy that requirement, we need to flush out any cached writes in nfs_getattr(). Speed things up slightly by not committing the writes.
  • NFS: support large reads and writes on the wire
    Most NFS server implementations allow up to 64KB reads and writes on the wire. The Solaris NFS server allows up to a megabyte, for instance. Now the Linux NFS client supports transfer sizes up to 1MB, too. This will help reduce protocol and context switch overhead on read/write intensive NFS workloads, and support larger atomic read and write operations on servers that support them.
  • SUNRPC: Ensure that SIGKILL will always terminate a synchronous RPC call.
    ...and make sure that the "intr" flag also enables SIGHUP and SIGTERM to interrupt RPC calls too (as per the Solaris implementation).

The last item has been on my wishlist since 2.0.x; tears of joy are welling up in my eyes, it's like watching your kid graduate from college. :-p

NFS client updates

Posted Jan 11, 2006 2:15 UTC (Wed) by zblaxell (subscriber, #26385) [Link] (2 responses)

"SUNRPC: Ensure that SIGKILL will always terminate a synchronous RPC call."

I've been waiting for that patch since 0.98 or so. It's been broken so long I started to believe it was part of the spec. ;-)

NFS client updates

Posted Jan 11, 2006 23:50 UTC (Wed) by njhurst (guest, #6022) [Link] (1 responses)

What does this mean exactly, is it when a program is accessing an nfs file and the network goes down you can't kill the program?

NFS client updates

Posted Jan 12, 2006 0:53 UTC (Thu) by zblaxell (subscriber, #26385) [Link]

That's one of the effects.

The addition of lazy umounts and "umount -l" was a major step forward in
this area (you still couldn't kill the processes, but you could drop the
mount point so that you didn't get any more stuck on the dead NFS mount).
Solving the real problem of course is much better. ;-)

I also did things like mess with firewalls and NAT configuration until I
could convince the localhost to talk to its own NFS server (the tricky
part is doing this remotely with a live net-connected machine without
disrupting all of the server's other clients at the same time). This led
to "Stale NFS file handles" all over the place, but at least the RPC
calls would complete and the machine could get on with killing processes.

NFS client updates

Posted Jan 13, 2006 19:52 UTC (Fri) by pimlott (guest, #1535) [Link]

it's like watching your kid graduate from college. :-p
... after six years. :-)

Looking forward to 2.6.16

Posted Jan 10, 2006 23:54 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

One thing I've been wondering for a while: what does `uevent' actually stand for, and why is it considered more euphonious than `hotplug'?

(I hope it's not `user event'; that'd be a rather bad choice of name. Typing on the keyboard is a user event. Coldplugging hda is unlikely to be.)

(Oh, and Greg, Kay, if you're reading this, thanks again for udev; I don't hotplug much, but I use udev regardless, as for sheer elegance udev, especially the new udevsynthesize/shell script/uevent/udevd scheme, is one of the nicest designs I've seen in a long time.)

Looking forward to 2.6.16

Posted Jan 11, 2006 0:32 UTC (Wed) by gregkh (subscriber, #8) [Link] (2 responses)

Yeah, it means "userspace event", sorry we could not not come up with a better name.

But it does describe what is happening, userspace is being notified that
something happened in the kernel.

And it's better than "hotplug" which is overloaded way too much these
days (hotplug memory, hotplug cpu, hotplug usb devices, etc.) and we export
more information through the uevent interface than just "hotplug" add
and remove events these days.

Looking forward to 2.6.16

Posted Jan 11, 2006 4:29 UTC (Wed) by iabervon (subscriber, #722) [Link] (1 responses)

So you deny that it's part of a plot to turn Linux into a ukernel? :)

Looking forward to 2.6.16

Posted Jan 11, 2006 4:42 UTC (Wed) by gregkh (subscriber, #8) [Link]

I completly deny that plot. If you look at the mess that is the driver core that I helped create, you would know that I'm all about the big, monolithic kernel model :)

Correction on IFB

Posted Jan 12, 2006 11:22 UTC (Thu) by dion (guest, #2764) [Link] (1 responses)

It's not "Internet Functional Block", it's "Intermediate Functional Block", it has been described here:

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/li...

It is by no means obscure for people who'd like to do ingress shaping.

Currently you can only do traffic shaping on egress, that means that if you have a router with 3 internal interfaces then each interface will be shaped separately, so each segment of the network can get a maximum of 1/3 of the available bandwidth, this sucks if there are two leechers on one net and none on the other.

With IFB (or IMQ previously) you can set up a virtual network device between your Internet line and the rest of the network so all the incoming traffic can be shaped together.

Correction on IFB

Posted Jan 12, 2006 13:42 UTC (Thu) by corbet (editor, #1) [Link]

Typo fixed, thanks.

The rest is just from the commit message. There's a bit more in the patch itself, but it still doesn't just jump out at relatively slow people (like your editor...)

Ugh...

Posted Jan 12, 2006 22:17 UTC (Thu) by roelofs (guest, #2599) [Link] (2 responses)

The block_device_operations structure has a new method getgeo(); its job is to fill in an hd_geometry structure with information about the drive.

...what a hideous name. "geo" == "Earth," was my first thought, followed immediately by "what the heck does that mean?" and then "maybe 'get geography'??". One extra letter buys you "getgeom()", which is as close to unambiguous as most abbreviations get...but "getgeo()"? Ugh.

Let's go rename all computer/communication/common/comparison/completion-related things to "com" while we're at it. Hrmph.

Curmudgeonly,
Greg

Ugh...

Posted Jan 14, 2006 20:41 UTC (Sat) by jzbiciak (guest, #5246) [Link] (1 responses)

Let's go rename all computer/communication/common/comparison/completion-related things to "com" while we're at it. Hrmph.

Oh, is that what the .COM bubble was about. And here I thought it was some strange plot between my serial ports (COM1: and COM2:) and the Common Object Mode taking over commercial interests. :-)

Ugh...

Posted Jan 14, 2006 20:44 UTC (Sat) by jzbiciak (guest, #5246) [Link]

s/Common Object Mode/Component Object Model/

Either my coffee hasn't kicked in, or this is a secret plot by COMMAND.COM to make me look bad.


Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds