Slashdot Mirror


Linux Kernel 2.6.21 Released

diegocgteleline.es writes "Linus Torvalds has released Linux 2.6.21 after months of development. This release improves the virtualization with VMI, a paravirtualization interface that will be used by Vmware. KVM does get initial paravirtualization support along with live migration and host suspend/resume support. 2.6.21 also gets a tickless idle loop mechanism called 'Dynticks', built in top of 'clockevents', another feature that unifies the timer handling and brings true high-resolution timers. Other features are: bigger kernel parameter-line, support for the PA SEMI PWRficient CPU and for the Cell-based 'celleb' Toshiba architecture, NFS IPv6 support, IPv4 IPv6 IPSEC tunneling, UFS2 write, kprobes for PPC32, kexec and oprofile for ARM, public key encryption for ecryptfs, Fcrypt and Camilla cipher algorithms, NAT port randomization, audit lockdown mode, some new drivers and many other small improvements."

9 of 296 comments (clear)

  1. Tickless only for x86 now, still good news by MarcQuadra · · Score: 5, Interesting

    I follow prerelease kernels and I've been waiting for this. I've found that running my VMWare hosts and guests with tickless, low-HZ, voluntary-preempted kernels is seriously reducing the overhead you get when you run more virtual CPUs than real ones in your box.

    I can't wait for it to mature on PPC, MIPS, and x86_64! Right now it's 32-bit x86 only.

    --
    "Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
  2. Re:Meh by FudRucker · · Score: 3, Interesting

    personally i hate using an initrd.img and prefer to build ext2 & ext3 support right in the kernel making initrd unnecessary, if you compile file system support as a module you will need an initrd.img too so insetead of selecting an "M" select "*" you could try that...

    P.S. i never use reiserfs so i can not say if this works with reiserfs or not...

    --
    Politics is Treachery, Religion is Brainwashing
  3. You joke, by StarKruzr · · Score: 5, Interesting

    but I wonder if we're ever going to see 2.8 at this rate. The current kernel revision is MILES away in technology from 2.6.0. What will it take to move to 2.8, or (dare I say it?) 3.0? What qualifies as a major enough change?

    --

    +++ATH0
  4. Mactel MBP C2D by JumboMessiah · · Score: 3, Interesting

    As an owner of a Macbook Pro, I've been waiting for this to get released. The Dynticks integration will (hopefully) help lower power consumption and heat output. Though this will help reduce heat and power on all platforms, those running Linux on a MBP C2D know it's hard to keep the fans from spinning up from relatively little activity.

    Next up is to get ATI to actually support any power saving features in fglrx on the MBP C2D and give the mAdWiFi guys more time to work out the features on the Atheros AR5008.

    OSX, right now, still has a significant advantage in keeping heat and power consumption down. Even though, I imagine some will testify that even OSX is having a hard time with it...

    Here's to testing out 2.6.21 tonight :)

  5. Re:Sooner or later... by ctr2sprt · · Score: 3, Interesting

    Yeah, the absurdly long kernel command lines in Linux really bug me. It's a symptom of the suckiness that is the PC BIOS, so I'm not really blaming the Linux people, but there are better solutions and have been for years. The FreeBSD loader, for instance, is capable of loading the kernel and any modules required to bootstrap the system, reading configuration files, and running Forth (!) scripts. Such a loader would completely eliminate the need for initrds on nearly all systems[1] without sacrificing any power. You could also emulate Openboot or EFI - or more realistically a subset of them - using the PC BIOS to prepare for the future.

    [1] initrd is a really awesome feature and it shouldn't go away. But it's massive overkill the way it's typically used, which is to load modules required to mount the root filesystem.

  6. Re:Does it still crash after 49.7 days?? by Tom · · Score: 4, Interesting

    It doesn't and never did. However, the uptime clock wraps around after 497 days. Took me two hours of finding out why the box rebooted (and then why there was no indication of the reboot in the logs) one day to research that. That same box has since looped the clock a second time. So I can say for sure it stays up for more than 50 days. :-)

    --
    Assorted stuff I do sometimes: Lemuria.org
  7. eCryptfs public key by omnirealm · · Score: 4, Interesting

    The public key support for eCryptfs can handle more than just public keys. It includes a communication mechanism with a user daemon that can be queried from the kernel on file open events. There is a pluggable key module interface accessible through that daemon. OpenSSL is currently implemented, but there is nothing stopping anyone from writing a module to use GnuPG or any other key management/encryption backend, all in userspace. The module just needs to accept a key signature, and it can perform encryption and decryption based on whatever that signature refers to.

    In other news, eCryptfs has recently been given the go-ahead for inclusion into Fedora:

    https://bugzilla.redhat.com/bugzilla/show_bug.cgi? id=218556

    In the meantime, you can grab all the userspace stuff from the eCryptfs SourceForge site:

    http://ecryptfs.sourceforge.net/

    --
    An unjust law is no law at all. - St. Augustine
  8. Re:Meh by giorgosts · · Score: 3, Interesting

    My feisty has a 35% chance of mounting correctly the swap and ntfs partitions. On other occasions it boots ok, most of the times displays error and I have to reboot. I have the ext3 and swap partitions on PATA disk and ntfs on a SATA. Anyone else experienced that?

    I also notice the new feisty to be much faster, but when under load, desktop slows down considerably. On edgy, however hard you loaded the machine, there was always the extra power for sth else if you wanted.

    Feisty looks feels like a windows machine now.

  9. Re:Meh by tinkertim · · Score: 3, Interesting

    personally i hate using an initrd.img and prefer to build ext2 & ext3 support right in the kernel making initrd unnecessary, if you compile file system support as a module you will need an initrd.img too so insetead of selecting an "M" select "*" you could try that...


    Its not just the file system you need, its the ability to spin the drive containing said file system too :) Its legacy HW that's getting fuzzy , not file systems. Not really sure why you hate initrds so much?

    The initrd does many more things than load drivers. What if you have an AoE based storage network with many disk-less stations needing to use an OCFS2 single system image? Initrd's can do neat things besides loading modules, have a look at linuxrc. You can bring network adapters to an up/link state, negotiate iscsi targets, download a boot config from a resource controller, all kinds of goodies. Complex networks need to do lots of things before pivot_root gets called, and we need complex networks.

    piix hasn't been 'quite right' since 2.6.16.29 on most of the legacy servers using PATA (IDE) I still have up and working, many of us have been having a difficult time with it. But progress is progress, and this is good progress so I guess my move to all SAS will be sooner than later.