WHAT'S NEW IN KERNEL DEVELOPMENT

WHAT'S NEW IN KERNEL DEVELOPMENT  Linus Torvalds doesn't just make  whatever changes he wants to the  kernel. Sometimes he goes through  the normal procedure of sending  code to the relevant maintainers.  Recently he sent a patch to AI  Viro, trying to speed up the VFS by  migrating some data out of SELinux  and into the inode data structure.  Linus also went on a brief tirade  about security features, and how  some of them ended up slowing  down performance by 50%, before  he and Al fixed it. He and Casey  Schaufler (the Smack maintainer)  had a bit of a dispute over that.  Casey said security folks cared a lot  about performance and had to deal  with hostile tirades like Linus' all  the time, and so were motivated to  do better.  Once upon a time, 32-bit kernels  were so cool. Nowadays, they  are scorned with derisive sneers.  Linus Torvalds recently remarked,  “anybody who runs a 32-bit kernel  with 16GB of RAl\/l doesn't even  understand how flawed and stupid  thatis.”    However, some popular  distributions still ship with 32-bit  kernels by default, and Pierre-  Loup A. Griffais recently pointed  out that this was causing huge  slowdowns for unsuspecting users.  The problem is bad enough that  Rik van Riel suggested giving  32-bit kernels a hard limit of 8 or  12GB of RAM, regardless of how  much physical RAM was present  on a given system. He added that  the kernel also should print a  friendly warning “to inform users  they should upgrade to a 64-bit  kernel to enjoy the use of all of  their memory."  Regardless of this patch, the  problem with distributions may  persist. As H. Peter Anvin put it,  “We kernel guys have been asking  the distros to ship 64-bit kernels  even in their 32-bit distros for  many years."  Linus Torvalds went on vacation  and temporarily lost the ability  to make tarball releases of new  kernel versions. He updated his git  tree, but he apologized for the lack    of tarballs. He also speculated that maybe  nobody even used the tarballs anymore, now  that git existed.  However, Randy Dunlap and Mikael  Pettersson immediately replied that they did  indeed rely on the tarball method. And, Linus  reassured them that he'd keep putting out  tarballs for the moment.  Nathan Zimmer posted a patch to  parallelize RAM initialization. Typically  during bootup, RAM is initialized by a single  CPU, before any other CPUs are started up.  On Nathan's system, this caused boot times of  more than an hour. With his patch, the CPUs  would all be brought up first, and then RAM  could be initialized by all of them together,  over much less time.  Originally, he made ita configuration  option, but Greg Kroah-Hartman said there  was no reason for that-just make it an  intrinsic feature. Clearly no one would choose  to configure a slower boot time.-zncmnowu