Before the 2.6.25 merge window closed...

The 2.6.25 merge window closed on February 10, after the merging of an eye-opening 9450 non-merge changesets. Most of the changes merged for 2.6.25 were covered in the first and second "what got merged" articles. This, the third in the series, covers the final 1900 patches merged before the window closed.

User-visible changes include:

• There are new drivers for SC2681/SC2691-based serial ports, Dallas DS1511 timekeeping chips, AT91sam9 realtime clock devices, Compaq ASIC3 multi-function chips, Cell Broadband Engine memory controllers, Marvell MV64x60 memory controllers, PA Semi PWRficient NAND flash interfaces, Marvell Orion NAND flash controllers, Freescale eLBC NAND flash controllers, Sharp Zaurus SL-6000x keyboards, Fujitsu Lifebook Application Panel buttons, IPWireless 3G UMTS PCMCIA cards, intelligent storage device enclosures, Winbond W83L786NG and W83L786NR sensor chips, Texas Instruments ADS7828 12-bit 8-channel ADC devices, and Sony MemoryStick cards.

• Also added are updated video drivers for Radeon R500 chipsets (2D acceleration is now supported) and Intel i915 chipsets (suspend and resume now work properly).

• Several more obsolete OSS audio drivers have been removed. The old mxser driver has also been removed in favor of mxser_new, now called simply "mxser."

• File descriptors returned by inotify_init() now support signal-based (using SIGIO) I/O. There is also a new notification event (IN_ATTRIB) sent when the link count of a watched file changes.

• The mac80211 (formerly Devicescape) wireless subsystem is no longer marked "experimental."

• The memory use controller for containers has been merged. This controller was described in this LWN article, but the patch has evolved somewhat since then and the details have changed. Some documentation can be found in Documentation/controllers/memory.txt.

• ACPI thermal regulation support has been added; see Documentation/thermal/sysfs-api.txt for details on how it works. The ACPI code also now supports the Windows Management Instrumentation interface, and uses that support to make recent Acer laptops work.

• ACPI now provides support for users who want to override their system's Differentiated System Description Table (DSDT).

• The XFS filesystem now supports the fallocate() system call.

• ATA-over-Ethernet (AoE) now properly supports devices with multiple network interfaces (and, thus, multiple paths to the host).

• Support for the MN10300 architecture (little-endian mode only) has been added.

• Support for a.out binaries has been removed from the ELF loader. Pure a.out systems will still work, though.

• Disk I/O statistics (as seen in /proc/diskstats and under /sys/block) have been augmented with more information about request merging and I/O wait time.

• The S390 architecture now implements dynamic page tables - processes will use 2-, 3-, or 4-level page tables depending on the size of their address space.

• The ext4 "in development" flag has been added; mounting an ext4 filesystem will now require an explicit "I know this might explode" option.

Changes visible to kernel developers include:

• Many nopage() methods have been replaced by the newer fault() API; the near-term plan is to remove nopage() altogether. See this article for a description of the new way of "page not present" handling.

• This cycle has also seen a bit of a reinvigoration of the long-stalled project to eliminate the big kernel lock. A number of BKL-removal patches have been merged, with more certainly to come.

• A generic resource counter mechanism was merged as part of the memory controller patch set; see <linux/res_counter.h> for the details.

• reserve_bootmem() has a new flags parameter. Most callers will set it to BOOTMEM_DEFAULT; the kdump code, though, uses BOOTMEM_EXCLUSIVE to ensure that it is the only one to touch the memory.

• Most architectures now have support for cmpxchg64() and cmpxchg_local().

• There is a new set of string functions:

      extern int strict_strtoul(const char *string, unsigned int base, 
                                unsigned long *result);
      extern int strict_strtol(const char *string, unsigned int base,
      	       		     long *result);
      extern int strict_strtoull(const char *string, unsigned int base,
                                 unsigned long long *result);
      extern int strict_strtoll(const char *string, unsigned int base,
                                long long *result);
  

  These functions convert the given strings to various forms of long values, but they will return an error status if the given string value, as a whole, does not represent a proper integer value. These functions are now used in the parsing of kernel parameters.

At this point, the merging of features is done (though there has been a bit of pushing for one or two things to slip in) and the stabilization period begins. With luck, that process will go a little more quickly than it did with 2.6.24.

---

(Log in to post comments)

And don't forget, you now need perl to compile the kernel, which you 
never needed before.

There are some things worth worrying about, but I don't think this is one 
of them. The kernel can be cross-compiled, so its build requirements are 
really not that important. Nobody sane ever compiles Linux on an embedded 
system (by definition if it's embedded it's too small to do that sort of 
thing), and 99.999% of non-embedded Linux systems have Perl on them.

A Perl installation requires about 30Mb. There's no way you could sensibly 
compile a modern Linux kernel on a system with that little RAM, so what 
you're saying is we should optimize the kernel build process for systems 
that have less disk space than we need memory to complete the compilation?

This isn't so much premature optimization as pointless optimization.

(And no, I don't much like Perl: I much prefer Python and C. But still, 
this is a waste of human effort.)

> There are some things worth worrying about, but I don't think this is
> one of them. The kernel can be cross-compiled, so its build
> requirements are really not that important. Nobody sane ever compiles
> Linux on an embedded system (by definition if it's embedded it's too
> small to do that sort of thing), and 99.999% of non-embedded Linux
> systems have Perl on them.

Apparently, I'm not sane then.

http://landley.net/code/firmware

I cross compile just enough of a native environment to be able to 
recompile itself, and then I boot it under qemu (where I have unlimited 
memory, hard drive, and can leverage cheap x86 CPU power) and native 
compile under an emulator.  Native compiling is MUCH easier than cross 
compiling, in general.

I accelerate this by using distcc to call out to the cross compiler 
(through the virtual network).  That's optional, but provides a nice 
speed boost without taking away from the fact that header #including and 
library linking and ./configure and all the _hard_ bits are run natively 
inside the emulator, where they "just work" without having to do the 
intricate and extensive "explaining things to the build, with a brick" 
that cross compiling requires.

> A Perl installation requires about 30Mb. There's no way you could
> sensibly compile a modern Linux kernel on a system with that little
> RAM, so what you're saying is we should optimize the kernel build
> process for systems that have less disk space than we need memory to
> complete the compilation?

No, I'm saying that gratuitous environmental dependencies more or less 
killed the gnucash project, and Linux has until now gone out of its way 
to avoid them.  There's _shipped logic to avoid the need for lex and yacc 
in kconfig, and you can run "oldconfig" without curses.  This perl 
dependency did not previously exist, and was introduced for very little 
reason.  Now there's talk of adding perl to kbuild.  So understanding the 
build process would now involve knowing three languages (Because nothing 
says "maintainability" like perl.  Or for that matter, having to know 
four different programming languages (C, BASH, gnu make, perl) to follow 
the build.)

Of course Python is just as widely deployed, so let's add that too.  (I 
love Python.  It doesn't belong in the kernel build unless perhaps you 
use it to REMOVE the dependencies on make and bash.)  And java's GPLv2 
now, why not throw that in as well?  Did you know PHP can be used 
standalone outside of web browsers?  And there are tons of fans of emacs 
lisp...

Where does it end?

> (And no, I don't much like Perl: I much prefer Python and C. But still, 
> this is a waste of human effort.)

Perl is not a language.  Perl is a program.  There are dozens of C 
compilers out there, several different javascript interpreters, even a 
python interpreter implemented in java.  But there is only a single 
implementation of perl, and attempts by the original development team to 
reimplement perl (in parrot) failed.  There is no standard, just a 
codebase that may or may not run your program.

The open source world was upset about Word files being considered a 
standard, and uncomfortable back when "it works on Netscape" was the sole 
definition of HTML, but Perl gets a pass on this.  I still don't 
understand why.  The IETF always insisted on two independent 
implementations before calling anything a standard.  To this day, Perl 
wouldn't pass muster there.

But that's a side issue.  So is perl's status as a write-only language.  
My objection is over adding complexity to the build process (in the form 
of environmental dependencies) without a compelling reason that outweighs 
the added complexity.

> I cross compile just enough of a native environment to be able to 
> recompile itself, and then I boot it under qemu (where I have unlimited 
> memory, hard drive, and can leverage cheap x86 CPU power) and native 
> compile under an emulator.  Native compiling is MUCH easier than cross 
> compiling, in general.

Wow, that's weird. I'm not sure it's a common use case to be worth making 
changes for, but it's not as if this change is huge. :)

(I haven't found setting up cross compilers to be remotely as hard as you 
have, though, even without crosstool to help. For kernel builds (thus 
without libraries), it verges on trivial, certainly much easier than 
getting qemu working.)

> No, I'm saying that gratuitous environmental dependencies more or less 
> killed the gnucash project

g-wrap, and endless backend thrashing, more or less killed the gnucash 
project :) every distro on earth has guile and GNOME packaged. More recent 
gnucashes have dropped g-wrap and moved to SWIG, thank goodness.

> build process would now involve knowing three languages (Because nothing 
> says "maintainability" like perl.  Or for that matter, having to know 
> four different programming languages (C, BASH, gnu make, perl) to follow 
> the build.)

Call me an elitist but I'd be inclined to say that if you can't pick up 
languages as simple as C, the subset of make used in kernel makefiles, and 
so forth you probably shouldn't be hacking the kernel at all. (And I don't 
think I've ever met a kernel hacker who doesn't know shell: perl is 
similar enough to the shell that you can pick up enough to read it in a 
few hours, or less.)

You really are setting up some seriously weak straw men here. Your real 
motive is obviously minimalism for the sake of it, so why on earth not 
admit it?

> Of course Python is just as widely deployed, so let's add that too.  (I 
> love Python.  It doesn't belong in the kernel build unless perhaps you 
> use it to REMOVE the dependencies on make and bash.)  And java's GPLv2 
> now, why not throw that in as well?  Did you know PHP can be used 
> standalone outside of web browsers?  And there are tons of fans of emacs 
> lisp...

I'm not sure if this is straw men or taking the mickey. I'd expect random 
slashdotters to spot the logical fallacies here.

(Regarding Perl not being a language, you're probably right, at least in 
regard to Perl 5. Perl 6 *does* have a language spec, though.)

> My objection is over adding complexity to the build process (in the form 
> of environmental dependencies) without a compelling reason that
> outweighs the added complexity.

Yet you seem to have no objection to adding complexity by reimplementing 
the wheel in the actual code to avoid the environmental overheads. That 
would be strange if your reasons weren't actually minimalism for the sake 
of it :)

Hi Nix,

Usually you're pretty accurate, but I have to disagree with you here:

> Nobody sane ever compiles Linux on an embedded system (by definition if 
> it's embedded it's too small to do that sort of thing)

I work on embedded systems here, and technically speaking there's no reason why you couldn't
build the Linux kernel using them. It would take a lot longer, but it's perfectly doable.
(I've compiled small things on the boards before, because it was just more convenient at the
time.)

So I think, really, your definition of embedded might need updating. You could always define
embedded as something too small to compile Linux. ;-)

Wow. Embedded systems have surely grown since I did anything with them. 
Can you really call a system 'embedded' if it has the 128Mb+ RAM 
practically needed to compile a kernel these days? (If you don't have 
swap, like many embedded systems, make that 256Mb.)

If it has that much RAM, you could probably stick Perl on it without 
hardly noticing, at least on your development box.

Like I said, it depends on your definition of embedded, I guess. I work with set-top boxes,
which most people tend to regard as embedded. I suppose you could start to define it by the
amount of RAM and CPU power available. :-)

I'd notice putting Perl on it, but that's because I'd have to build it first. Python doesn't
seem to like cross-compiling for mipsel; no idea if Perl is better.

(For what it's worth, the dev system here has both 256Mb and an attached hard disk I could use
for swap if needed. Production boards can be differently configured, though.)

Oh - I wasn't actually commenting on the Perl dependency for the kernel build, btw, just the
view of embedded systems.