"I'm please to announce [the] POHMEL high performance network filesystem. POHMELFS stands for Parallel Optimized Host Message Exchange Layered File System," began Evgeniy Polyakov, explaining:

"This is a high performance network filesystem with local coherent cache of data and metadata. Its main goal is distributed parallel processing of data. Network filesystem is a client transport. POHMELFS protocol was proven to be superior to NFS in lots (if not all, then it is in a roadmap) operations."

This latest release prompted Jeff Garzik to reply, "this continues to be a neat and interesting project :)" New features include fast transactions, round-robin failover, and near-wire limit performance. This adds to existing features which include a local coherent data and metadata cache, async processing of most events, and a fast and scalable multi threaded user space server. Planned features include a server extension to allow mirroring data across multiple devices, strong authentication, and possible data encryption when transferring data over the network. Evgeniy linked to several benchmarks in his blog.

Jeff Garzik posted a two patch series introducing an asynchronous event notification infrastructure, "enabling SATA Asynchronous Notification ('AN') for CD/DVD devices that support it." He summarized:

"For devices that support SATA AN (only very recent ones do), this means that HAL and other userspace utilities no longer need to repeatedly poll the CD/DVD device to determine if the user has changed the media."

The first patch is for the SCSI driver and is based on work originally done by Kristen Carlson Accardi, along with "copious input from James Bottomley". The second patch updates libata to utilize the new SCSI event infrastructure.

"The __deprecated marker is quite useful in highlighting the remnants of old APIs that want removing. However, it is quite normal for one or more years to pass, before the (usually ancient, bitrotten) code in question is either updated or deleted," explained Jeff Garzik, posting a small patch to make it possible to silence "warning: 'foo' is deprecated" type messages.

Andrew Morton wasn't impressed, suggesting, "Sigh. Can't we just fix the dud code? Or mark it BROKEN and see what happens?" Linus Torvalds added, "I think removing __deprecated is the better option. Quite frankly, some people add '__deprecated' *way* too eagerly." Jeff agreed that __deprecated is over used, "__deprecated has spread to just about every API that people don't consider fresh and up-to-date." He then added ,"like I noted in the patch description, rewriting grotty ISA/MCA/etc. probe code is a thankless, boring task that few are crazy enough to attempt :) As you can see from the patch flood recently I /have/ been working through the dud code, but it will still take years. The changes required for each are on average ~200 LOC changed, if not more."

Jeff Garzik posted a series of nine patchs to the lkml titled to "remove [the] 'irq' argument from all irq handlers", explaining, "the overwhelming majority of drivers do not ever bother with the 'irq' argument that is passed to each driver's irq handler. Of the minority of drivers that do use the arg, the majority of those have the irq number stored in their private-info structure somewhere." He noted that he had no intention to push the patches upstream anytime soon.

Feedback was entirely positive, with Thomas Gleixner suggesting, "Full ACK. We should do this right at the edge of -rc1. And let's do this right now in .24 and not drag it out for no good reason." Ingo Molnar concurred, "full ACK on the concept from me too. Please go ahead! :)" Eric Biederman noted that there was still work to be done, "the practical question is how do we make this change without breaking the drivers that use their irq argument." Jeff agreed, explaining why the code won't be pushed upstream during -rc1, "I am finding a ton of bugs in each get_irqfunc_irq() driver, so I would rather patiently sift through them, and push fixes and cleanups upstream. Once that effort is done, everything should be in the 'trivial' pile and not have the logic that you are worried about (and thus there would be no need to add an additional branch to the irq handling path)."

Jeff Garzik posted a series of five patches for the forcedeth driver which he described as, "several proposed updates for testing". Forcedeth is a GPL'd driver for the Ethernet interface of the NVIDIA nForce chipset, originally merged into the 2.4.26 and 2.6.5 Linux kernels. Jeff noted two main goals for the patches:

"1) move the driver towards a more sane, simple, easy to verify locking setup -- irq handler would often acquire/release the lock twice for each interrupt.

"2) to eliminate a rarely used, apparently fragile locking scheme that includes heavy use of disable_irq(). this tool is most often employed during NIC reset/reconfiguration, so satisfying this goal implies changing the way NIC reset and config are accomplished."

Jeff explained that he was looking to get the changes tested, "these are intended for feedback and testing, NOT for merging." He went on to explain that one of the changes included two independent napi_structs, one for receiving and one transmitting, "I feel TX NAPI is a useful tool, because it provides an independent TX process control point and system load feedback point. Thus I felt this was slightly superior to tasklets. But who knows if this is a good idea? :) I am interested in feedback and criticism on this issue."

"I'm a bit behind after investigating the TCP performance issues that turned out to be HW specific problems. It's a bit of a disappointment, I thought maybe there was a cool bug to fix in TCP :-)" explained David Miller, posting his networking merge plans for the upcoming 2.6.24 kernel. He noted, "I merged in Jeff Garzik's and John Linville's latest and I'm running the current tree on my workstation most of today with good results so far." David added, "I plan to commit my Neptune driver in it's current state, and that's the last new feature going in."

In an earlier discussion last month on the Linux netdev mailing list, David described how many changes were in his net-2.6.24 git tree, "it's to the point where every single bug fix put into Linus's tree creates a merge conflict with net-2.6.24, we are simply touching that much stuff. :-)" He added, "we've touched so much in net-2.6.24 that we really should be auditing the thing and fixing any bugs that have been added. If you're bored and looking for something to do, pick an odd NAPI driver and audit it in the net-2.6.24 tree."

"What is going on whenever someone changes code is that they make a 'derivative work'," began Theodore Ts'o. "Whether or not you can even make a derivative work, and under what terms the derivative work can be licensed, is strictly up to the license of the original. For example, the BSD license says: 'redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met....' Note the 'with or without modification'. This is what allows people to change BSD licensed code and redistribute said changes." Regarding code that is GPL'd, he added, "it is not a relicencing, per se, since the original version of the file is still available under the original copyright; it is only the derived work which is under the more restrictive copyright."

Disagreement continued as to whether or not the BSD license allows the addition of new copyrights on unmodified or minimally modified code. Another disagreement was over the continued existence of improperly licensed files in developer source code repository histories from when BSD licensed files had been changed to the GPL, a problem since fixed. Jeff Garzik explained:

"In a purely open development environment, even personal developer trees are made public. That's the way we _want_ development to occur. Out in public, with a full audit trail. Your implied ideal scenario is tantamount to guaranteeing that mistakes are never committed to a public repository anywhere. Mistakes will happen. Even legal mistakes. In public.

"What you are seeing is an example of mistakes that were caught in review, and corrected. That's how any scalable review process works... the developer reviews his own work. the team reviews the developer's work. the maintainer reviews the team's work. the next maintainer reviews. and so on, to the top."

"I'm pleased to announce [the] fourth release of the distributed storage subsystem, which allows [you] to form a storage [block device] on top of remote and local nodes, which in turn can be exported to another storage [block device] as a node to form tree-like storage [block devices]," Evgeniy Polyakov stated on the Linux Kernel mailing list. The new release includes a new configuration interface and several bug fixes.

Network device driver and SATA subsystem maintainer, Jeff Garzik, was not impressed with the concept, "[distributed block devices] are not very useful, because it still relies on a useful filesystem sitting on top of the DBS." He went on to explain the problem, "it devolves into one of two cases: (1) multi-path much like today's SCSI, with distributed filesystem arbitrarion to ensure coherency, or (2) the filesystem running on top of the DBS is on a single host, and thus, a single point of failure (SPOF)." He proposed instead that time would be better spent developing a POSIX-only distributed filesystem, "in contrast, a distributed filesystem offers far more scalability, eliminates single points of failure, and offers more room for optimization and redundancy across the cluster." Jeff went on to caution, "a distributed filesystem is also much more complex, which is why distributed block devices are so appealing :)" When Lustre was pointed out as an existing option, Jeff noted, "Lustre is tilted far too much towards high-priced storage, and needs improvement before it could be considered for mainline."

Following a recent merge request, Linus Torvalds stressed that he was serious about not wanting to merge any big changes after the merge window closes, "get the changes in before -rc1, or just *wait*. If they aren't ready before the merge window opens, they simply shouldn't be merged at all." Jeff Garzik reiterated, "once -rc1 is out there, that means the focus should be on stabilizing the existing codebase. Pushing a big driver update means that effort must restart from scratch. We just don't want to go down that road, which a big reason for the merge window in general." Further when it was noted that the recent changes were heavily tested by the vendor, Jeff stressed the importance of community testing:

"Take a lesson from when I was on Linus's shit-list... twice: Twice, Intel submitted an e1000 update after the merge window closed. Twice, they claimed the driver passed their quite-exhaustive internal testing. And twice, the most popular network driver broke for large masses of users because I took a hardware vendor's word on testing rather than rely on the testing PROVEN to flush out problems: public linux kernel testing.

"I'm not singling out Intel, there are plenty of other hardware vendors that repeat the exact same pattern."

Keith Packard announced the availability of drivers for Intel's 965GM Express Chipset. Jeff Garzik responded, "great news. Here's hoping that Intel produces a standalone video card eventually, to further take away market share from closed source competitors." In Keith's announcement he explained:

"The Intel® 965GM Express Chipset represents the first mobile product that implements fourth generation Intel graphics architecture. Designed to support advanced rendering features in modern graphics APIs, this chipset includes support for programmable vertex, geometry, and fragment shaders.

"Extending Intel's commitment to work with the X.org and Mesa communities to continuously improve and enhance the drivers, support for this new chipset is provided through the X.org 2.0 Intel driver and the Mesa 6.5.3 releases. These drivers represent significant work by both Intel and the broader open source community."

The git directory content manager used to manage the Linux kernel source tree [story] continues to develop at a rapid pace [story]. Keeping up with the latest changes, Jeff Garzik released an updated version of his Kernel Hacker's Guide To Git. He explains, "several changes in git-core have made working with git a lot easier, so be sure to re-familiarize yourself with the development process."

Jeff's short guide is broken into four major sections, 'getting started' which talks about installing the software and getting a copy of the linux kernel source tree, 'basic tasks' which offers examples of keeping up to date with the latest code and merging in your own changes, 'branches' offering examples of creating, using and merging branches, and 'miscellaneous debris' which mentions applying patches from an mbox file and syncronizing tags. Further documentation on the various git commands can be found in the git man pages.