In a series of seven patches, Arnd Bergmann proposed adding in-memory write support to mounted cramfs file systems. He explained, "the intention is to use it for instance on read-only root file systems like CD-ROM, or on compressed initrd images. In either case, no data is written back to the medium, but remains in the page/inode/dentry cache, like ramfs does." Reactions were mixed. When Arnd suggested this as an alternative to using the more complex unionfs to overlay a temporary filesystem over a read-only file system, and that similar support could be added to other file systems, it was pointed out that there was ultimately more gained by focusing on a single solution that worked with all filesystems. David Newall stressed, "multiple implementations is a recipe for bugs and feature mismatch." Erez Zadok suggested, "I favor a more generic approach, one that will work with the vast majority of file systems that people use w/ unioning, preferably all of them." He went on to add that more gains would be had from modifying the union destination filesystem rather than multiple source filesystems. Arnd agreed in principle, but noted it would add complexity. He indicated that he'd explore the idea further, then explained:

"My idea was to have it in cramfs, squashfs and iso9660 at most, I agree that doing it in even a single writable file system would add far too much complexity. I did not mean to start a fundamental discussion about how to do it the right way, just noticed that there are half a dozen implementations that have been around for years without getting close to inclusion in the mainline kernel, while a much simpler approach gives you sane semantics for a subset of users."

"This patch series also introduces a new small shell script wrapper, called scripts/checkfiles, that checks the compliance of source files (not in diff format); the script can operate on any mix of files and directories (recursively checking)," Erez Zadok stated describing a patch posted to the Linux Kernel mailing list. The small script works by recursively walking through a specified directory, running checkpatch on a diff of each source file against /dev/null. Erez added, "I ran the above script and it found nearly 1.5 million reported warnings/errors, with drivers being the largest abuser, not surprisingly." He then offered a breakdown of the warnings within each top level directory, summarizing, "1,464,313 total, any volunteers? :-)"

Recent efforts to add additional details to Documentation/CodingStyle prompted Linus Torvalds to reply, "I'm not very happy with this." He explained:

"'CodingStyle' should be about the big issues, not about details. Yes, we've messed that up over the years, but let's not continue that. In other words, I'd suggest *removing* lines from CodingStyle, not adding them. The file has already gone from a 'good general principles' to 'lots of stupid details'. Let's not make it worse."

Erez Zadok pointed out, "there's a lot of good value in having all those details, as it helps people standardize on more common practices, including details. I think removing all those details may only increase the amount-of less-accepted code to be posted, resulting in more lkml people having to repeat themselves on what not to do." He went on to ask, "would you prefer if CodingStyle was reorganized or even split into (1) general principles and (2) details? Perhaps we need a CodingStylePrinciples and a CodingStyleDetails?" Linus responded favorably, "I'm certainly ok with the split into two files. What I'm not ok with is really important stuff (indentation), and then mixing in silly rules (`parenthesis are bad in printk's`?)"

Bharata Rao posted a query to the Linux Kernel mailing list looking for ideas on how to best handle filesystem namespace unification with Union Mount, "typically this is done by reading the directory entries of all the union'ed layers (starting from the top and working downwards) and merging the result by eliminating the duplicate entries. This is done by extending the getdents/readdir system calls to support the notion of union'ed directories." He went on to describe a few different methods they were considering for implementation noting, "he main problem in getting a sane readdir() implementation in Union Mount is the fact that a single vfs object (file structure) is used to represent more than one (underlying) directory. Because of this, it is unclear as to how lseek(2) needs to behave in such cases."

Two other similar solutions were discussed, aufs and UnionFS. In response to the Bharata's questions, Erez Zadok explained, "in the long run, storing a cache of the readdir state on disk, is the best approach by far. Since you already spend the CPU and memory resources to create a merged view, storing it on disk as a contiguous file isn't that much more effort. That effort pays off later on esp. if the directories don't change often"