login
Search
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."
"That's quite buggy and would have generated so many runtime warnings in a 'developer' setup (rofl) that I look at Documentation/SubmitChecklist and just weep."
"I don't care what anybody else says - x86 is *so* totally dominant, that other architectures have to live with the fact that 99.9% of all drivers are written for and tested on x86. As a result, anything else is 'theory'. Are some drivers good and are careful? Yes. Are most?
"I'm all edicted out. Sometimes one just puts forth the reasoning and lets others decide whether it's worth bothering about."
"Another week, another batch of mostly pretty small fixes. Hopefully the regression list is shrinking, and we've fixed at least a couple of the oopses on Arjan's list," said Linux creator Linus Torvalds, announcing the 2.6.26-rc5 kernel. He added, "as usual, the bulk of the changes are in drivers and arch code - together they are about 70% of the diffstat. And the arch stats are bloated by some new/updated SH and avr defconfig files, which is also fairly common at this stage." Linus concluded:
"Perhaps unusually, 13% is in kernel/, almost all of it fixing up some scheduler issues - with the bulk of it by far being a couple of reverts due to performance regressions. But there's a few other fixes too. And then there is networking and some ocfs2 updates. Along with various one-liners sprinkled all around.
"The shortlog (appended) gives a reasonable view of it all. Nothing hugely exciting sticks to my mind, but then I don't think we've had any really hugely exciting problem spots either.."
"A key reason that Linux has succeeded is that it actively seeks to work for a variety of people, purposes and products. One operating system is now a strong player in the embedded market, the real time market, and the High Performance Computing market, as well as being an important player in a variety of other markets. That's a rather stunning success."
Tony Luck offered some statistics focused on the frequency of developers that only contribute to the Linux kernel one time, "I skimmed through looking for drive-by contributors (defined as someone who contributes to just one release and is then never heard from again)." Starting with the 2.6.11 kernel, he suggested the following numbers: "63 [developers contributed patches] in version 2.6.11 [and then were] never seen again, 148 in version 2.6.12, 128 in version 2.6.13, 92 in version 2.6.14, 96 in version 2.6.15, 122 in version 2.6.16, 137 in version 2.6.17, 140 in version 2.6.18, 135 in version 2.6.19, 95 in version 2.6.20, 136 in version 2.6.21, 153 in version 2.6.22, 179 in version 2.6.23, 179 in version 2.6.24, and 304 in version 2.6.25".
It was pointed out that the statistics were artificially inflated due to name misspellings and other variations, and that many of the listed people are actually still working with the Linux kernel. Greg KH added, "well, you do know that the distribution of all of our users are: 50% only contributed 1 patch; 25% contributed 2; 12% contributed 3; 6% contributed 4 and so on?" He went on to point out:
"Our curve is leveling out much better now though. For the whole 2.5 release, the top 30 people did over 80% of the work. Now, the top 30 people are doing 30% of the work. So it is getting much better, as long as we still continue to keep our massive rate of change that we have going, and huge number of developers, we should be fine. So this list doesn't necessarily mean anything is wrong, only that 50% are one-time contributors. And I think that shows we are easy to get a change into our tree from just about anyone, not that we are driving people away."
"These random kernel boots found many 'impossible to trigger' bugs and races in the past. The reason for its race finding capability is the timing randomness of the resulting random kernel image: the delays caused by random combination of debugging facilities, build variants, kernel subsystem variants we have."
"The http://www.kerneloops.org website collects kernel oops and warning reports from various mailing lists and bugzillas as well as with a client users can install to auto-submit oopses," began Arjan van de Ven, referring to a website first announced last December. He summarized, "this week, a total of 3670 oopses and warnings have been reported, compared to 3029 reports in the previous week." The 'kerneloops' client is available from the project's web page, and is now being included by multiple distributions. Arjan explains, "in addition to Fedora, Debian now has included the client application in their default GUI install targets, thanks a lot for that!" He went on to discuss some recent changes:
"This week, based on feedback, I've split the report into 'untainted' and 'caused by proprietary drivers'. Let me know if I should continue doing this or if the old format was better.
"As an experiment (on request) I've exported the database to text files (one file per report) and stuck it in a git repository. You can take a look with git clone git://www.kerneloops.org/ Suggestions for improving the format of this are obviously very welcome, as are 'yes useful' and 'no not useful' comments. Again, this is an experiment, if it's not seen as useful I may discontinue it."
"I think our mistake is the assumption that everyone who wants to contribute to the kernel wants to code, or that everyone wants to end up at the top of the major feature contributors list. For lots of people, we're going to be that experiment from college they never quite want to admit to later on in life."
In April, 2.4 kernel maintainer Willy Tarreau queried the Linux kernel mailing list regarding how the 2.4 kernel is still being used. He followed up summarizing the responses, suggesting that about 5% of 2.4 users run the kernel on old recycled laptops at home or on PDA's and thin clients, running whatever works with no real need to upgrade. Another 5% of the users are on desktop PCs and monitoring stations, not upgrading because "it works". From there, about 50% of the users run the 2.4 kernel on general purpose servers and update regularly, still running the older kernel due to lack of need for new features and lack of time, and possibly due to failed earlier attempts to upgrade. Another 20% use the 2.4 kernel on application specific servers where reliability is of the highest importance. 10% of the users run the older stable kernel on routers, firewalls, and intrusion detections systems, with 1 to 2 year uptimes and limited updates in a business setting, and shorter uptimes and frequent updates in a personal setting. The final 10% or so use the kernel in embedded systems where stability is again very important, and the build tree may be highly modified, causing at least one major network equipment manufacturer to still be shipping devices with the 2.4.2 kernel. Willy continued:
"Based on that and on the workflow people took the time to explain, I realize that the distinction between -pre and -rc is useless (ding! Linus if you read this, don't beat me). In fact, either people want absolute reliability and they pick one kernel from the stable 2.4.X.Y branch, or they want more recent updates and they simply do their shopping in the -master branch, which is fairly easy thanks to the Gitweb interface. But there are almost no testers in 2.4, just users. That means that I don't have to expect immediate feedback when posting a pre-release. And it has happened several times that I got a build error report several weeks after the release.
"Also, since most people do not update more than 1 - 2 times a year, it's not very useful to have more than 1 - 2 new versions a year, especially since we have the stable release. For this reason, I think I will issue stable releases a bit more often for users to quickly get their fixes, but progressively increase the delay between major releases. Those ones will only be issued with new PCI IDs, major driver updates, compiler support, etc..."
"In the early days, the project was conceived as a way of getting fresh blood into kernel development by giving them fairly simple but generally useful tasks and hoping they'd move more into the mainstream," began James Bottomley starting a thread titled Fixing the Kernel Janitors project. He continued, "if we wind forwards to 2008, there's considerable and rising friction being generated by janitorial patches,", references a recent thread complaining about worthless patches hitting the lkml. Later in the thread he added:
"That's why I think we have to change the process. If we keep the Janitors project, then the bar has to be raised so that it becomes more participatory and thought oriented (i.e. eliminate from the outset anyone who is not going to graduate from mechanical changes to more useful ones). That's why I think bug finding and reporting is a better thing to do. There are mechanical aspects to finding bugs but it is a useful service. Bug fixing is participatory because we usually do quite a lot of back and forth between the reporter and the fixer and at the end of the day quite a few people get curious about how the bug was triggered in the first place and actually go off and read the code."
"Look at anyone who is extremely nimble with the kernel, and ask them what they worked on to get going with development. Did Andrew Morton fixup whitespace errors when he was starting to become familiar with the tree? Did I?
"My suggestion to you, and to everyone else who wants to improve the quality of this community, is to become a part of it. Learn a subsystem. Post patches that fix problems people care about. Listen to criticism and respond to it constructively."
"This is a high performance network filesystem with a local coherent cache of data and metadata. Its main goal is distributed parallel processing of data," Evgeniy Polyakov said, announcing the latest version of his Parallel Optimized Host Message Exchange Layered File System. He noted that in addition to numerous bugfixes, the latest release includes the following new features:
"Full transaction support for all operations (object creation/removal, data reading and writing); Data and metadata cache coherency support; Transaction timeout based resending, if [a] given transaction did not receive [a] reply after specified timeout, [the] transaction will be resent (possibly to different server); Switched writepage path to ->sendpage() which improved performance and robustness of the writing."
Evgeniy also noted that he has started working on support for parallel data processing, one of the key intended features of the filesystem. He explained that initial logic has been added so data can be written to multiple servers at the same time, and reads can be balanced across the multiple servers, though the logic is not yet being used by the filesystem.
