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."
I haven't been able to get anything past 2.6.17 to boot successfully, I think they seriously hosed the ATA shit.
Here.
You're confusing Linux with this Windows 95/98. However, this problem or this another problem are even more funnier
It's me who sent the headline. "Publicar" (to publish) is what people usually uses for those cases in spanish. So there you've the answer for your question :)
(I also planned to add the number of months of development (almost 3, 80 days), but I forgot it)
It means that they were able to successfully remove the blood sucking parasites from the kernel.
Most kernels use a periodic system timer tick to do various housekeeping chores, like rescheduling tasks, sending packets, flushing files from the cache, etc. Usually this occurs at some periodic rate, i.e. every 1-10ms for Linux and every 10-15ms for Windows (according to this article.
This is a bit wasteful of CPU resources, since the kernel might not need to do anything for quite a while, or it might want a high resolution timer with higher accuracy than normal system timer. For example, when the system is idle, the CPU still must wake up and process a timer interrupt for every timer tick, and if it's set to 1ms there are 1000 interrupts per second.
A tickless kernel instead only schedules the next tick for when it is needed, so if the system is idle and nothing needs to happen for 50ms, then the next tick will be scheduled 50ms later. On the other hand, if a timer needs to go off in 750 microseconds, the kernel can schedule the next interrupt to go off then, giving much higher accuracy.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
It doesn't work that way outside of x86-land. As another responder said, the PWRficient isn't just a CPU, it's a SoC (System on Chip). To compare to an x86 system, that would be like having a low-power CPU, north bridge, south bridge, SATA controller, ethernet controller (but not PHY), memory controller, I2C interface, USB controller, interrupt controller, etc. all wrapped up on one chip. This is quite common in the embedded world, where most PPCs are used these days (I'm working on one myself in my day job).
Since each SoC is totally different, except maybe for the CPU core, porting Linux (or any OS) to it is a little more difficult than just compiling it and loading it. Check out the arch/ppc or arch/arm directories for examples of all the different chips supported. While the work certainly isn't comparable to, say, porting Linux to an entirely different CPU architecture, it does require several new files with custom code to support things like the way interrupts are assigned to the specific functions on the SoC.
Worse, sometimes new drivers need to be written for certain on-chip peripherals, because some bonehead empire-building managers at the chipmaker wanted to justify a higher budget for their department by, instead of just re-using an existing USB controller or Ethernet controller design and plopping that onto the chip, putting together a whole team and spending months creating a new controller because it might improve performance by a whopping 5%. My last company, which made a lot of ARM-based chips, was especially guilty of this.