|
|
Subscribe / Log in / New account

Coming soon to a kernel near you

When last week's summary was written, the process of merging patches for 2.6.20 had just begun. Linus has been busy since then; some of the highlights of what has gone in appear below.

User-visible changes include:

  • The kernel can now operate with a 300Hz clock rate, which happens to work well with both 25 frame-per-second and 30 FPS video.

  • New drivers for the real-time clock on OMAP1 chips, the AES engine on Geode LX processors, IBM GXT4500P display cards, DiBcom DiB7000M and DiB7000P demodulators, Pinnacle 400e DVB-S USB receivers, Phillips IP3204 I2C controllers, Atmel AT91 I2C controllers, Winbond W83793 hardware monitoring chips, National Semiconductor PC87427 hardware monitoring chips, and Apple Motion Sensors. The "usbvision" driver has been merged, adding support for "more than 50" USB video camera devices. Finally, your editor's drivers for the "Cafe" camera controller and OmniVision OV7670 sensor (both used in the OLPC system) have been merged.

  • The kernel can now (on i386 systems) be built in an entirely relocatable manner. This feature is most useful for people who install a second kernel in memory to generate crash dumps.

  • Support for the Liskov-Rivest-Wagner block cypher has been added.

  • A large set of fixes and enhancements for the GFS2 filesystem have been merged; these include support for TCP connections in the lock manager.

  • Support for I/O accounting has been improved. There is a new file (/proc/pid/io) where a process's statistics may be read (though the netlink-based taskstats interface remains the preferred way to get this data).

  • Support for Intel's hardware virtualization features (via /dev/kvm) has been merged.

Changes of note for kernel developers include:

  • Attempts to build the kernel with gcc 4.1.0 will generate warnings, since this compiler is known to make mistakes.

  • Fixes for code broken by the workqueue changes continue to find their way into the tree. If you have to deal with some of this code, these instructions may prove helpful.

  • As if the workqueue changes were not enough, there is also now a "freezable" workqueue type, being a workqueue which can be frozen early in the suspend-to-disk process. These queues are created with create_freezeable_workqueue(); there is no single-threaded version available.

  • There is also a new run_scheduled_work() function which will cause a previously-scheduled work_struct to run synchronously, assuming it has not already run elsewhere.

  • The internal __alloc_skb() function has a new parameter, being the number of the NUMA node on which the structure should be allocated.

  • The slab allocator API has been cleaned up somewhat. The old kmem_cache_t typedef is gone; struct kmem_cache should be used instead. The various slab flags (SLAB_ATOMIC, SLAB_KERNEL, ...) were all just aliases for the equivalent GFP_ flags, so they have been removed.

  • A new boot-time parameter (prof=sleep) causes the kernel to profile the amount of time spent in uninterruptible sleeps.

  • dma_cache_sync() has a new argument: the device structure for the device doing DMA.

  • The paravirt_ops code has gone in, making it easier for the kernel to support multiple hypervisors.

  • The struct path changes have been merged, with changes rippling through the filesystem and device driver subsystems.

  • The fault injection framework has been merged.

  • There is now a generic layer for human input devices; the USB HID code has been switched over to this new layer.

  • A new function, round_jiffies(), rounds a jiffies value up to the next full second (plus a per-CPU offset). Its purpose is to encourage timeouts to occur together, with the result that the CPU wakes up less frequently.

  • The block "activity function," a callback intended for the implementation of disk activity lights in software, has been removed; nobody was actually using it.

The merge window remains open, as of this writing, so expect a few more things to go in before 2.6.20 takes its final shape.


to post comments

Coming soon to a kernel near you

Posted Dec 14, 2006 3:23 UTC (Thu) by intgr (subscriber, #39733) [Link]

Correction: LRW (Liskov-Rivest-Wagner) is a mode of operation of block ciphers, meant for use in disk encryption, but is not a block cipher by itself.

Coming soon to a kernel near you

Posted Dec 14, 2006 4:02 UTC (Thu) by aliguori (subscriber, #30636) [Link] (4 responses)

KVM also supports AMD's virtualization extensions (not just Intel's).

Coming soon to a kernel near you

Posted Dec 14, 2006 4:35 UTC (Thu) by bronson (subscriber, #4806) [Link] (3 responses)

And will probably become very useful very fast. http://kvm.sourceforge.net/

Coming soon to a kernel near you

Posted Dec 14, 2006 11:32 UTC (Thu) by rvfh (guest, #31018) [Link] (2 responses)

The linked page is unclear, but I seem to remember that you need special hardware (new processors basically) for that, am I wrong?

Coming soon to a kernel near you

Posted Dec 14, 2006 12:52 UTC (Thu) by drag (guest, #31333) [Link] (1 responses)

The hardware (your cpu and motherboard) have to support VT (intel) or AMD-V (or SVM) to use this.

This means Core Duo, Pentium-D 9xx (not 8xx), and Xeons. Maybe a couple others. I have one. Pentium-D on a Asus 945G. (Nice.)

You need to have support in the motherboard also. If you don't have support, but you feel your cpu should support it.. look for a bios upgrade to add support.

For AMD any AM2 socket CPU except Sempron will support the SVM stuff. Also telling is if your AMD cpu supports DDR2 then it will support the extesions.

The userland stuff is essentially a slightly modified Qemu VM.

Coming soon to a kernel near you

Posted Dec 15, 2006 3:16 UTC (Fri) by nlucas (guest, #33793) [Link]

    ... This means Core Duo, Pentium-D 9xx (not 8xx) ...

Actually, being a Pentium-D 9xx it's not enough. It needs to be 9x0.
As an example, a Pentium D 940 has VT support, while 945 doesn't.

300Hz clock rate

Posted Dec 15, 2006 10:05 UTC (Fri) by ldo (guest, #40946) [Link] (1 responses)

>...which happens to work well with both 25 frame-per-second and
>30 FPS video.

Except nobody I know uses 30 fps video. NTSC is 29.97 fps. Or is that 30000/1001 fps?

300Hz clock rate

Posted Dec 16, 2006 4:46 UTC (Sat) by lordsutch (guest, #53) [Link]

Well, ATSC (HDTV) is at 24/30/60 frames per second, exactly.


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