|
The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown. |
Jesse Barnes has coded some improved panic output for the kernel. The problem is that if you're running the X window system, and you get a kernel panic, traditionally you wouldn't necessarily be able to view the panic output on screen. Gaining access to that information is important for debugging the crash, and it's actually pretty amazing that there are any circumstances where the kernel has enough time to display this information during a crash. Jesse's patches increase the likelihood of seeing panic output even when running X. But, as he says, if X has disabled the display, his patches won't get the output onto the screen. So it's not a perfect solution, but it's a big incremental improvement over what we have now.
He only got a lukewarm response. He got no reply from Linus Torvalds or David S. Miller, to whom he'd actually submitted the patches. Maxim Levitsky did comment and initially liked the patches, but then there was some confusion and Jesse's patches were thought to prevent systems from starting up again after hibernating. Eventually, it was decided that Jesse's patches weren't to blame for this. Maxim confirmed that the patches worked fine on his system, but there was still no further discussion of that patches. So, it's unclear if they just fell under the radar, or if there's some other problem with the patches that Linus and David think Jesse needs to address.
Carlos Chinea announced his implementation of High Speed Synchronous Serial Interface (HSI), designed to link a Linux system with a cell phone or with any handset fitted with a cellular modem.
There was no real discussion. Randy Dunlap objected to the requirement that HSI be built into the kernel. He felt it should be able to be compiled as a module. But Carlos replied that this just hadn't been implemented yet, and Randy said as long as it was in the works, that would be fine.
Sebastien Jan also reviewed Carlos's code but had no real criticism, because they'd spoken about the design earlier and were fairly well aligned on it already. So, it looks as though no obstacles have appeared to prevent including this in the kernel.
The Hardware Locality team (hwloc) announced version 1.0, which they considered to be the first production-ready version. They invited everyone to try it out. The basic idea of hwloc is to provide an abstraction layer for lots of hardware elements of a system, so developers can code up their features, and the abstraction layer will make them run on all architectures, or at least many.
Andi Kleen was unimpressed, saying that Linux basically had this already. Samuel Thibault pointed out that Linux didn't have a uniform tree of information that was consistent across all architectures, and that hwloc provided this. The discussion didn't continue, so it's unclear whether the benefits are enough to entice kernel developers into using it. If you're interested in checking them out yourself, there's an hwloc website at http://www.open-mpi.org/projects/hwloc/.
Tim Chen and friends discovered that if multiple threads used TmpFS at the same time, there would be a lot of lock contention, causing a significant slowdown. This was especially a problem as the number of CPUs on the system increased. Tim and his cohorts implemented a way to avoid lock contention that resulted in a 270% throughput improvement in one of their tests. Andi Kleen reviewed the patches and liked them and also commented that their approach - implementing a token jar - could also be useful in other parts of the kernel.
Alan Ott had been frustrated by the lack of documentation for SysFS and libudev, so he wrote his own versions and put them online at http://www.signal11.us/oss/udev/. SysFS is a filesystem used for reporting on and configuring hardware devices and other kernel internals. Libudev is a C library used for walking through SysFS, tracking any changes to the observed system, and making configuration changes via the filesystem interface. Kay Sievers offered some constructive criticism of Alan's documentation. No one suggested that it be actually incorporated into the kernel source tree, but that seems like a logical place for it to live, ultimately.
Recently, the question came up of whether GCC 3.x really needs to be supported as a choice for compiling Linux kernels, at least under the x86 platform. H. Peter Anvin remarked that the developers had been seeing more and more 3.x problems cropping up under x86, and maybe it would be better just not to worry about fixing them anymore. He solicited opinions, and some folks seemed fine with it. Ingo Molnár suggested giving deprecation warning for a while first so that no one was caught off guard. Andi Kleen suggested that there were still distributions using GCC 3.x as the default compiler, but Peter said people probably weren't using it to compile bleeding-edge kernels on those distros. Justin P. Mattock remarked that any distro relying on GCC 3.x should just upgrade.
No clear decision came out of the discussion, though people seemed generally unopposed. But a few days later, Peter submitted a batch of fixes, including one to fix the compile breakage under GCC 3.x. Tetsuo Handa also sent in a GCC 3.x fix at around the same time, and Peter asked why he was compiling kernels with such an old compiler; but there was no discussion about it.
Elsewhere, in the midst of several folks working to figure out fixes for GCC 3.x, Eric Dumazet made a plea in favor of continuing to support GCC 3.x for x86. He said it wouldn't take much work to maintain the support, and the developers should only drop support if there was some real reason, not just because that compiler was "old."
So, it looks as though the pressure to ditch 3.x will continue to increase as the difficulty of doing so increases, while there still seems to be a group of folks willing to keep supporting it. For that kind of situation, I'd expect GCC 3.x to be compiling kernels on the x86 architecture for years to come.
James Morris announced the 2010 Linux Security Summit, taking place at the same and location as this year's LinuxCon. He put out a call for contributors and invited anyone interested to attend, regardless of any particular involvement with security issues. There's a website with more info (https://security.wiki.kernel.org/index.php/LinuxSecuritySummit2010) and a mailing list (https://ext.namei.org/mailman/listinfo/linux-security-summit). The organizers forming the Program Committee include representatives from various companies and at least one US government agency. There was no discussion, but security issues are so fun and surprising that it should be a great summit.
To be sure a new computer would run Linux, someone asked which hardware Linus Torvalds, Alan Cox, and other big-time kernel hackers used. Valdis Kletnieks replied that this wasn't a sure-fire method of getting a Linux-compatible piece of hardware. For one thing, Valdis said, top kernel people might be using incompatible hardware they had specifically kludged a kernel for. Or, he went on, their specific hardware configuration might not be available anymore. Also, they might have a weird hardware setup that requires a strange .config file that would be harder to support for the rest of the Linux community. Also, he concluded, they might have hardware with known problems that just didn't bother them in their day-to-day usage.
Valdis remarked that Andrew Morton was known to have used a Vaio at one point. Alan Cox said the best bet was to buy the most common hardware because that was the most likely to be maintained. He also said, "I wouldn't, however, try to clone my hardware setup - parts of it are there *because* it doesn't work well in Linux!" Bill Davidsen echoed this, remarking, "... if [developers] are anything like me, they will change hardware regularly for one reason or another."
Ted Ts'o said a lot of kernel developers liked ThinkPads, particularly the T- and X-series, and pointed out that selecting a previous generation would mean more kernel developers would have likely found and fixed bugs that affected it. He also said that Linux Foundation members got discounts on ThinkPads, which might explain their popularity.
That said, if you're considering building your own system, it's worth searching to see whether a particular piece of hardware has a particular problem with Linux.