|
|
Log in / Subscribe / Register

The 2.6.19 process begins

The 2.6.19 merge window has opened, and the flood of patches into the mainline has begun. As of this writing, it has only begun - the 2000 or so patches which have been merged after 2.6.18 are likely to be outnumbered by those that remain. Here's what has found its way in so far, starting with the user-visible changes:

  • The OCFS2 filesystem is no longer marked "experimental."

  • A number of InfiniBand updates, including better RDMA support and drivers for some new adapters.

  • Support for IPv6 policy routing rules - and a mechanism for the creation of multiple IPv6 routing tables to support those rules.

  • The parallel ATA driver patch set.

  • The labeled networking patch set implementing the Commercial IP Security Option.

  • Support for the Atmel AVR32 architecture.

  • Super-H support for Titan, SH7710VoIPGW and I-O DATA Landisk boards.

  • Big updates to the PowerPC and S/390 architectures. Among other things, S/390 has gained KProbes support.

  • New drivers for external flash on ATSTK1000 boards, TI OMAP1/2 i2c busses, ESI Miditerminal 4140 devices, Areca RAID controllers, SuperTrak EX8350/8300/16350/16300 SCSI controllers, QLogic QLA3xxx network interfaces, IBM eHEA Ethernet adapters, and the Ethernet controller found on Cirrus Logic ep93xx boards. The controversial aic94xx driver, originally written by Luben Tuikov and since revised by a number of others, has also been merged.

Changes visible to kernel developers include:

  • The CHECKSUM_HW value has long been used in the networking subsystem to support hardware checksumming. That value has been replaced with CHECKSUM_PARTIAL (intended for outgoing packets where the job must be completed by the hardware) and CHECKSUM_COMPLETE (for incoming packets which have been completely checksummed by the hardware).

  • A number of memory management changes, including tracking of dirty pages in shared memory mappings, making the DMA32 and HIGHMEM zones optional, and an architecture-independent mechanism for tracking memory ranges (and the holes between them).

  • The pud_page() and pgd_page() macros now return a struct page pointer, rather than a kernel virtual address. Code needing the latter should use pud_page_vaddr() or pgd_page_vaddr() instead.

  • A number of driver core changes including parallel device probing and some improvements to the suspend/resume process.

  • There is now a notifier chain for out-of-memory situations; the idea here is to set up functions which might be able to free some memory when things get very tight.

  • The semantics of the kmap() API have been changed a bit: on architectures with complicated memory coherence issues, kmap() and kunmap() are expected to manage coherency for the mapped pages, thus eliminating the need to explicitly flush pages from cache.

  • PCI Express Advanced Error Reporting is now supported in the PCI layer.

  • A number of changes have been made to the inode structure in an effort to make it smaller.

  • The no_pfn() address space operation has been added.

For anybody who is curious about what else is likely to be merged, Andrew Morton's 2.6.19 -mm merge plans document is worth a look. Highlights include another set of memory patches (with ongoing discussion over whether making ZONE_DMA optional makes sense), a rework of the network time protocol code, the vectored AIO patch set (maybe), a long list of NFS improvements, eCryptfs (though there is some opposition here), various device mapper and RAID improvements, and a number of changes to the generic IRQ layer.

Additionally, Andrew plans to merge a couple of container-oriented patches: virtualization for the utsname and IPC namespaces. Says Andrew:

This doesn't really make sense on its own, so there's an act of faith here - it assumes that Linux will eventually have full-on virtualisation of the various namespaces with sufficient coverage to actually be useful to userspace.

Normally I'd just buffer all the functionality into -mm until it's ready to go and is actually useful to userspace. But for this work that would mean just too many patches held for too long. So I'll start moving little pieces like this into mainline.

One thing which is not likely to go in is reiser4, which is still held up on various needed fixes. So this filesystem looks like it will wait for yet another development cycle.


to post comments

The 2.6.19 process begins

Posted Sep 28, 2006 14:57 UTC (Thu) by dambacher (subscriber, #1710) [Link] (3 responses)

Just reciting from somewhere up:
"Based von Leitner's benchmarking methodology Linux has the fastest file system - reiser4."

Oops .-)

The 2.6.19 process begins

Posted Sep 29, 2006 13:16 UTC (Fri) by Klavs (guest, #10563) [Link] (1 responses)

why is that an oops? just because it's fast (in the workload he appereantly used it in) doesn't mean it's stable (like in doesn't throw your files away ;)

The 2.6.19 process begins

Posted Sep 29, 2006 18:07 UTC (Fri) by nlucas (subscriber, #33793) [Link]

And the new experimental network protocol that no one uses and seems to be the origin of most of the security patches is stable?

I never used Reiser4 and I don't even dare to try to really understand the reasons why it isn't included in the kernel, but I don't think anyone can say "stable" is a requirement for a kernel patch (there is that big EXPERIMENTAL tag for this things).

Besides, I don't think the ammount of Reiser4 users will agree with you on that count.

On the other hand, I do use Reiser3. And the main reason is just because of the fast fsck time on bootup (and it never did eat my drive. real hardware problems of cheap drives have been taking care of that part).

The 2.6.19 process begins

Posted Sep 29, 2006 22:02 UTC (Fri) by dale77 (guest, #1490) [Link]

Ditto that oops. reiser4 should be in there with an EXPERIMENTAL tag.
Currently this is looking like filesystem censorship based on pricked
personalities.

Dale


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