Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic|
Table Of Contents
|1.||20 Jun 2005 - 24 Jun 2005||(23 posts)||Asynchronous I/O Gets A Boost|
|2.||20 Jun 2005 - 24 Jun 2005||(36 posts)||Struggling To Remove DevFS|
|3.||21 Jun 2005 - 27 Jun 2005||(15 posts)||Difficulties Probing For IDE Hardware|
|4.||23 Jun 2005 - 24 Jun 2005||(6 posts)||Status Of SPI Development|
|5.||24 Jun 2005 - 29 Jun 2005||(50 posts)||Abortive New ndevfs Replacement For DevFS|
|6.||24 Jun 2005||(9 posts)||Bug Hunting With git|
|7.||24 Jun 2005 - 26 Jun 2005||(7 posts)||New Oops Reporting Tool (ORT)|
|8.||26 Jun 2005 - 30 Jun 2005||(60 posts)||Linux 2.6.12-mm2 Released; Crash Bug Identified And Fixed|
|9.||26 Jun 2005 - 27 Jun 2005||(5 posts)||Dell Systems Management Base Driver|
|10.||27 Jun 2005 - 1 Jul 2005||(23 posts)||Patch Review For Upcoming 126.96.36.199 Stable Release; Some Dissent On Acceptance Policies|
|11.||28 Jun 2005 - 29 Jun 2005||(15 posts)||Linux 2.6.13-rc1 Released|
|12.||29 Jun 2005||(2 posts)||Linux 188.8.131.52 Released|
|13.||30 Jun 2005 - 4 Jul 2005||(78 posts)||Status Of Merging FUSE|
|14.||1 Jul 2005 - 4 Jul 2005||(23 posts)||Linux 2.6.13-rc1-mm1 Released|
|15.||4 Jul 2005||(1 post)||Linux 2.4.32-pre1 Released|
|16.||5 Jul 2005 - 6 Jul 2005||(33 posts)||Linux 2.6.13-rc2 Released|
|17.||6 Jul 2005 - 7 Jul 2005||(6 posts)||SecurityFS Generic Security Filesystem For Security Modules|
Mailing List Stats For This Week
We looked at 3229 posts in 19MB. See the Full Statistics.
There were 1050 different contributors. 404 posted more than once. The average length of each message was 104 lines.
|The top posters of the week were:||The top subjects of the week were:|
|93 posts in 430KB by andrew morton
83 posts in 375KB by greg kh
63 posts in 634KB by johannes stezenbach
60 posts in 425KB by greg kh
54 posts in 395KB by christoph lameter
|68 posts in 282KB for "fuse merging?"
50 posts in 216KB for "[announce] ndevfs - a "nano" devfs"
49 posts in 202KB for "updated git howto for kernel hackers"
42 posts in 183KB for "mercurial vs updated git howto for kernel hackers"
35 posts in 171KB for "[git patch] remove devfs from 2.6.12-git"
These stats generated by mboxstats version 2.8
1. Asynchronous I/O Gets A Boost
20 Jun 2005 - 24 Jun 2005 (23 posts) Archive Link: "Pending AIO work/patches"
Topics: FS: NFS, POSIX, Samba
People: Suparna Bhattacharya, Trond Myklebust, Sébastien Dugué, Andi Kleen, William Lee Irwin III, Jeremy Allison, Chris Mason, Zach Brown, Benjamin LaHaise
Suparna Bhattacharya said:
Since AIO development is gaining momentum once again, ocfs2 and samba both appear to be using AIO, NFS needs async semaphores etc, there appears to be an increase in interest in straightening out some of the pending work in this area. So this seems like a good time to re-post some of those patches for discussion and decision.
Just to help sync up, here is an initial list based on the pieces that have been in progress with patches in existence (please feel free to add/update ones I missed or reflected inaccurately here):
On my part, I'll start by re-posting (1) for discussion, and then move to (2).
Trond Myklebust said of item 5, "I'm working on something that attempts to define per-arch low-level primitives (essentially wrappers to the current arch specific code). I expect to post something in the next 2 weeks (or at least before the kernel summit)..."
Sébastien Dugué said of item 3, "I'm currently running some benchmarks (sysbench + MySQL) using AIO, results will be available soon. I will also release libposix-aio V0.5 at the same time. (2) will sure help cleanup our code."
Elsewhere, Suparna said:
Here is a little bit of background on the motivation behind this set of patches to update AIO for filtered wakeups:
As I was rewriting the patches to address this, there is one other change I made to resolve one remaining ugliness in my earlier patchsets - special casing of the form
if (wait == NULL) wait = &local_wait
to switch to a stack based wait queue entry if not passed a wait queue entry associated with an iocb.
To avoid this, I have tried biting the bullet by including a default wait bit queue entry in the task structure, to be used instead of on-demand allocation of a wait bit queue entry on stack.
All in all, these changes have (hopefully) simplified the code, as well as made it more up-to-date. Comments (including better names etc as requested by Zach) are welcome !
Andi Kleen remarked, "I looked over the patches and they look all fine to me." Benjamin LaHaise also liked Suparna's patches, though he had his own suggestions. William Lee Irwin III added, "I'm going to keep going over these until I get tired of it for general bulletproofing purposes, but all indications thus far are good."
Later, Suparna said, "here are the patches that implement the changes to make filesystem AIO read and write truly asynchronous even without O_DIRECT. With these patches in place it will no longer be necessary for the POSIX AIO library (from S?bastien et al) to force O_DIRECT and memcpy for alignment. (Samba should find this useful)" And Jeremy Allison replied, "Wonderful ! That's exactly what we need - thanks. I could have fixed this in userspace but it would be rather ugly."
2. Struggling To Remove DevFS
20 Jun 2005 - 24 Jun 2005 (36 posts) Archive Link: "[GIT PATCH] Remove devfs from 2.6.12-git"
Topics: FS: devfs, FS: initramfs, FS: ramfs, Hot-Plugging, Small Systems
People: Andrew Morton, Greg KH, Bill Gatliff, Mike Bell, David Brownell, Miles Bader, Russell King, Arjan van de Ven
Greg KH posted a patch to entirely remove DevFS from the 2.6 kernel. Andrew Morton replied, "Whimper. Maybe we should cook this in -mm for a bit, get a feeling for how many users hate us, and how much?" Greg replied, "There might be some complaints. But I doubt they would be from anyone running a -mm tree as those people kind of know the current status of things in the kernel. There have been numerous warnings as to the fact that this was going away, and I waited a _year_ to do this. Also, no disto uses devfs only (gentoo is close, but offers users udev and a static /dev also.)" Andrew said, "What happens if we merge it and then the storm of complaints over the ensuing four weeks makes us say "whoops, shouldna done that [yet]"?" Arjan van de Ven suggested simply disabling the configuration option for a few weeks and see what that kicked up; and Andrew and Greg both agreed this would be a good test of the waters.
Some folks spoke up in favor of keeping DevFS, because of the amount of work it would be to switch to udev or some other solution. But other folks who had once been pro-DevFS also spoke in favor of removing it now. For these folks, they said the transition had been difficult, but as Bill Gatliff put it, "I've come this far somewhat reluctantly, but can see that udev is a better long-term solution. Once devfs is gone, it's easier for me to justify doing the work to go fully over to udev."
Mike Bell made an impassioned plea to keep DevFS. He said:
Once devfs is out, it's out for good. It is for all intents and purposes impossible to maintain such a thing outside of mainline. You should know that, udev's kernel infrastructure was developed pretty much entirely within mainline and look how long it took to get even the present number of drivers working with it.
It's pretty hard to put effort into devfs when said patches won't get merged because it has already been decided by certain people that devfs is not the way to go. For example the quick death without comment of the earlier devfs-on-top-of-tmpfs patches.
Or, look at how hard of a time udev had gaining mindshare, how long it was around for until now. Only shock tactics like marking devfs OBSOLETE (at a time when udev was completely unready to replace devfs, making it far from obsolete) got people switching.
He also remarked somewhat bitterly, "It breaks a lot of my embedded setups which have read-only storage only and thus need /dev on devfs or tmpfs. With early-userspace-udev-on-tmpfs being - in my experience - still unready. Not to mention the general bother of having to change dozens of desktop/server systems to work with udev, but I doubt you care about that." Andrew spoke up to thank Mike for his input. Andrew agreed that "that's quite a problem. We're certainly causing people such as yourself to take on quite a lot of work. But on the other hand we do want the kernel to progress sanely, and that sometimes involves taking things out. I don't have enough info to know whether the world would be a better place if we keep devfs, remove devfs or remove devfs even later on. I don't think anyone knows, which is why we're taking this little disable-it-and-see-who-shouts approach."
Close by, David Brownell remarked, "I'd agree that embedded setups are the ones that have been slowest to switch over, for various reasons. One of them is that many LKML folk ignore embedded systems issues; "just PC class or better". Another has been that the basic hotplug scripts never worked well with "ash", and who's going to want to ship "bash" and friends? :) Those problems seem resolved with 2.6.12 and current modutils and udev. Leaving basically an "upgrade your userspace" requirement." Miles Bader had to take issue with David's statement that LKML folks didn't care about embedded systems. He said, "maybe the average LKMLer doesn't actively worry so much about embedded issues, I've found many of them are very friendly and helpful in getting patches for embedded/small-system functionality cleaned up and merged into the mainstream kernel." Russell King also agreed with this.
Greg pointed out to Mike that DevFS had been on the chopping block for over a year, and folks who used it should have been preparing for its eventual demise. He said if people hadn't been planning ahead, it was pretty much their own fault if they ended up with a lot of work now. He added, "for embedded systems, there are packages to build it and put it in initramfs. People have already done the work for you."
Mike defended his position, and a flamewar seem imminent, but Greg said, "I've taken the time that I would have spent responding to this email thread, and to other people who for some reason don't like to respond to mailing lists but want to pester me privatly with "don't delete devfs" type emails, and written ndevfs, a replacement in less than 300 lines (including all needed hooks in the kernel). If this does not meet your needs to keep devfs for your embedded systems, please respond to the ndevfs post with the patch on lkml." And that was it. The thread was over.
3. Difficulties Probing For IDE Hardware
21 Jun 2005 - 27 Jun 2005 (15 posts) Archive Link: "PATCH: IDE - sensible probing for PCI systems"
Topics: Disks: IDE, PCI
People: Alan Cox, Maciej W. Rozycki
Alan Cox said:
Old ISA/VESA systems sometimes put tertiary IDE controllers at addresses 0x1e8, 0x168, 0x1e0 or 0x160. Linux thus probes these addresses on x86 systems. Unfortunately some PCI systems now use these addresses for other purposes which leads to users seeing minute plus hangs during boot or even crashes.
The following patch (again has been in Fedora for a while) only probes the obscure legacy ISA ports on machinea that are pre-PCI. This seems to keep everyone happy and if there is someone with that utterly weird corner case the ide= command line still provides a get out of jail card. Unsurprisingly we've not found anyone so affected.
Maciej W. Rozycki remarked, "FYI, for MIPS for machines with a PCI bus we only probe for ISA IDE ports on if there's a PCI-ISA or PCI-EISA bridge somewhere there. This might be a good idea for the i386 and probably any platform using PCI as well." Alan replied:
The primary/secondary ISA ports show up in PC systems because of the PCI IDE class devices being in compatibility mode not native mode (so you can still run old OS's). There are also a couple of older weird cases.
The PCI layer code is smart enough to figure out when a PCI and an ISA probe find the same device and to put the entire thing together properly so that aspect of it is ok.
For the 3rd and higher ports probing them isn't safe on a PCI box regardless of the presence of ISA bridges so I don't think we need the extra complexity - or am I missing something ?
The code is OK with me, but I've been wondering whether a more general approach would be possible. And poking blindly at any of these ports, including the "traditional" primary and secondary IDE interfaces, is unsafe if there is no legacy bridge in the system, because you either hit an innocent arbitrary device that happens to have a BAR configured for that range or get a master abort (I'm not sure what it results in for the i386 -- an NMI?) if nobody listens.
Actually there should have always been a set of BARs for the (E)ISA in legacy bridges, which would have made the whole mess be avoided, sigh...
4. Status Of SPI Development
23 Jun 2005 - 24 Jun 2005 (6 posts) Archive Link: "[RFC] SPI core -- revisited"
Topics: I2C, SPI
People: dmitry pervushin, Jamey Hicks, Russell King
Dmitry Pervushin said, "we finally decided to rework the SPI core and now it its ready for your comments.. Here we have several boards equipped with SPI bus, and use this spi core with these boards; Drivers for them are available by request (...and if community approve this patch)" Jamey Hicks replied:
I'm glad to see that work is progressing on SPI core. I've worked on drivers on both ARM linux and Blackfin uclinux that use SPI and would prefer that they not be platform specific.
What I've found in my Blackfin work is that I need asynchronous SPI support. The driver starts an SPI transaction and receives a callback when the SPI transaction has completed. The operations are similar to what you've suggested, except that the message structure includes a pointer to a callback and a void *data pointer.
The driver I'm working on is for the Chipcon CC2420 802.15.4 radio, which uses SPI to access its registers and transmit and receive FIFOs. In my CC2420, it queues SPI requests and initiates the next one when an SPI transaction completes.
Russell King replied:
I worry about SPI at the moment because I can't see how it's being used from just this code.
The worry I have is that it appears to contain an algorithm layer. Would this be better as a library for drivers to use, or something like that?
The reason I bring up this point is that my L3 layer is over-complex for what it does (despite being about 378 lines) because it tried far too hard to look like the I2C layer - soo much so I'm not happy with it for mainline.
Jamey thought a library could be a good idea. He said, "I think the only algorithm that really gets shared is the bitbanging one, which could be a library, and otherwise it is controller specific and might as well be in the adapter."
5. Abortive New ndevfs Replacement For DevFS
24 Jun 2005 - 29 Jun 2005 (50 posts) Archive Link: "[ANNOUNCE] ndevfs - a "nano" devfs"
Topics: FS: devfs, FS: sysfs, Version Control
People: Greg KH, Mike Bell, Matt Mackall, J.A. Magallon
Greg KH created ndevfs, a very small replacement for DevFS. He said, "It doesn't allow subdirectories, and only uses LSB compliant names. But it works, and should be enough for people to use, if they just can't wean themselves off of the idea of an in-kernel fs to provide device nodes. Now, with this, is there still anyone out there who just can't live without devfs in their kernel?" Mike Bell replied:
this is pretty much all I asked for. A simple kernel filesystem to export device nodes with names, rather than just the numbers as sysfs does. The "detecting non-existant device names" thing never meant anything to me personally, and if anyone does care this gives them a simple place to add such a hook - unlike device names I don't see why such a thing would be difficult to maintain as a patch.
It'll obviously need support for symlinks, directories and mknod. And I'm not sure you can change the mode/owner of those devices yet. Also, I have no idea what the device support is like yet (am currently in the middle of nowhere, getting the latest bk to test this patch with over my handphone would not be fun) but looking at the bit where it's getting the names from the device model I can see it encountering problems with oddly named devices. And any devices which aren't dynamic in udev obviously aren't going to work with this patch either.
He added, "If devfs could be left alone (disabled, if necessary) until something like this was working, I would be completely mollified."
J.A. Magallon also liked Greg's implementation. But Matt Mackall said to Greg, "Hmm. I'm not pleased. Perhaps you're pleasing the wrong people?"
And Greg replied:
You are so right, I am. I need to be pleasing me, and devfs in the kernel is not the correct solution. I knew this 4 years ago when Pat and I started working on the driver core (my main goal was to do it to support a udev-like solution), and I still know this today.
So no, I'm not going to be submitting this. But what it is, is a nice proof-of-concept for people who "just can't live without a in-kernel devfs" to show that it can be done in less than 300 lines of code, and only 6 hooks (2 functions in 3 different places) in the main kernel tree. That is managable outside of the main kernel for years, with almost little to no effort.
He added, "Thanks for calling me on this, I appreciate it. You weren't the only one either, which is a good thing."
6. Bug Hunting With git
24 Jun 2005 (9 posts) Archive Link: "Finding what change broke ARM"
Topics: Version Control
People: Russell King, Linus Torvalds, Dave Hansen
Russell King said:
When building current git for ARM, I see:
CC arch/arm/mm/consistent.o arch/arm/mm/consistent.c: In function `dma_free_coherent': arch/arm/mm/consistent.c:357: error: `mem_map' undeclared (first use in this function) arch/arm/mm/consistent.c:357: error: (Each undeclared identifier is reported only once arch/arm/mm/consistent.c:357: error: for each function it appears in.) make: *** [arch/arm/mm/consistent.o] Error 1
How can I find what change elsewhere in the kernel tree caused this breakage?
With bk, you could ask for a per-file revision history of the likely candidates, and then find the changeset to view the other related changes.
With git... ? We don't have per-file revision history so...
Linus Torvalds replied:
Ahhah! A real-world example of what cool things git can do.
Anyway, the first starting point is _exactly_ the same as under BK, except the syntax is very different, and git does it better, in fact:
git-whatchanged -p arch/arm/mm/consistent.c
However, in this case nothing has changed in that file over the whole git history, so you get an empty answer. Let's go to phase two, but first a comment:
He went on, regarding Russell's comment about per-file history, saying:
We don't _store_ changes as per-file revision histories, but we do store it in a way where finding out what happened is efficient even per-file. While a line-by-line "annotate" is not efficient, the "what changed" certainly is.
And git actually does better than BK (or _any_ per-file history thing), because "git-whatchanged" actually works over directories or multiple independent files too, and it works purely on pathnames, so you can say "git-whatchanged" for a file that has gone away to see _why_ it went away. In most other systems it's really hard to see what happened to something that isn't there any more..
Anyway, the problem clearly didn't happen because of any changes to that file at all, so here per-file history simply doesn't help. But never fear, we're not screwed yet. In particular, you will now obviously suspect that since it wasn't that _file_ that changed, and since you know what changed in the ARM code, it's going to be a generic linux header file change that screwed you over.
So phase #2 is to do
git-whatchanged -p include/linux
(which shows every commit that touches include/linux, and shows that part as a patch, thus the "-p"). That starts up a pager on the results by default, so we just be stupid about it and do a "/mem_map" to look for changes that mention mem_map. Maybe we'll be lucky.
Even that doesn't show a whole lot: but it does point a very suspicious finger to the recently merged sparse-mem stuff from Andy Whitcroft, though.
And now you have a commit to look at, namely the "sparsemem memory model" one, commit ID d41dee369bff3b9dcb6328d4d822926c28cc2594.
In fact, looking at it, I think it's simply config option changes, and probably the SPARSEMEM config option that has preempted your lack of DISCONTIGMEM support. But now you have somebody to blame and to ask for help from: Andy Whitcroft and Dave Hansen, whom I've cc'd.
I might start phase #3 with
git-whatchanged -p mm/Kconfig arch/arm/Kconfig
but at this point you may already have enough of a clue that you don't even care any more.
7. New Oops Reporting Tool (ORT)
24 Jun 2005 - 26 Jun 2005 (7 posts) Archive Link: "[ANNOUNCE] ORT - Oops Reporting Tool"
People: Michal Piotrowski
Michal Piotrowski said:
Here is our (see copyright section ;)) simple script that help to create
a bug report:
Why do we do this?
Because many people don't have time to prepare a good (with all importrant pieces of information) bug report.
How does it work?
It creates file with information about your system (software, hardware, used modules etc.), add file with oops into it and in the future sends it to the chosen mainterner or lkml.
How can you help?
If you know something about bash scripting you can review it, add some useful features and make some optimalisations. Or just send me an idea.
There was a generally positive reaction, and various folks offered small suggestions for improvements.
8. Linux 2.6.12-mm2 Released; Crash Bug Identified And Fixed
26 Jun 2005 - 30 Jun 2005 (60 posts) Archive Link: "2.6.12-mm2"
Topics: Hyperthreading, Kernel Release Announcement, PCI, SMP
People: Andrew Morton, Reuben Farrelly, Ingo Molnar
Andrew Morton announced Linux 2.6.12-mm2, saying:
A reminder that there is a vger mailing list for tracking patches which are added to -mm. Do
`echo subscribe mm-commits | mail [email protected]'
Reuben Farrelly identified a reproducible bug introduced with this release. An oops "seems to happen at slightly different places in the bootup, especially at the end." Andrew replied, "Why do you keep breaking my kernel?"
Andrew asked Reuben to send in his .config file, which he did; and Andrew replied, "The bug is in the new spinlock debugging code itself. Ingo, can you test that .config please? Reuben, I guess disabling CONFIG_DEBUG_SPINLOCK will get you going."
Ingo Molnar banged away at this configuration, and finally reported:
couldnt reproduce it on an UP box, nor on an SMP/HT 2/4-way box, but it finally triggered on a 2-way SMP box.
the bug is that current->pid is not a unique identifier on SMP (doh!).
The patch below fixes the bug - which also happens to be a speedup for the debugging code, as the ->pid dereferencing does not have to be done anymore. Also, i've disabled the panicing for now.
Reuben confirmed that Ingo's patch fixed the problem.
9. Dell Systems Management Base Driver
26 Jun 2005 - 27 Jun 2005 (5 posts) Archive Link: "[PATCH][RFC 2] char: Add Dell Systems Management Base driver"
People: Doug Warzecha
Doug Warzecha said:
This patch adds the Dell Systems Management Base driver.
The Dell Systems Management Base driver is a character driver that implements ioctls for Dell systems management software to use to communicate with the driver. The driver provides support for Dell systems management software to manage the following Dell PowerEdge systems: 300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC, 650, 1655MC, 700, and 750.
By making a contribution to this project, I certify that: The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file.
10. Patch Review For Upcoming 184.108.40.206 Stable Release; Some Dissent On Acceptance Policies
27 Jun 2005 - 1 Jul 2005 (23 posts) Archive Link: "[00/07] -stable review"
People: Chris Wright, Andrew Morton, Jean Delvare
Chris Wright said:
Most of the patches were quite small, but one was larger, and Jean Delvare had some objections. First of all, the description of the patch was, "Return to previous held-logic of calling scsi_add_host() only after the board has been completely initialized. Also return pci_*() error-codes during probe failure paths. This also corrects an issue where only lun 0 is being scanned for a given port." Jean felt this was not complete enough, and didn't identify any critical bugs to fix. He also went over the patch piece by piece, and found several areas that he felt did not belong in the -stable tree. But Andrew Morton said, "The threshold for "what belongs in -stable" is a) set too high and b) over-zealously enforced." He added that the patch was "obviously safe", and went on, "Let's use our brains on these patches and not become beholden to doctrine, OK?" Chris agreed with these sentiments. But Jean replied, "Why did we write down and discuss rules for -stable in the first place then? Of the 9 rules Greg first listed as conditions for a patch to be accepted in -stable, this patch breaks 4 (it is bigger than 100 lines, if fixes more than one thing, including one that doesn't bother people as far as I can see, and it has trivial fixes in it.) So I don't think I am actually splitting hair as you seemed to suggest."
11. Linux 2.6.13-rc1 Released
28 Jun 2005 - 29 Jun 2005 (15 posts) Archive Link: "Linux 2.6.13-rc1"
Topics: Digital Video Broadcasting, Kernel Release Announcement, Networking
People: Linus Torvalds, Bill Davidsen
Linus Torvalds announced Linux 2.6.13-rc1, saying:
There was a lot of stuff pending after 2.6.12, and in the week and a half since the release, the current diff against it has grown to almost three megabytes compressed.
Which is actually normal for a -rc1 release judging by the two last ones, but it usually takes us longer than ten days to get there. Which just shows that 2.6.12 was brewing for too long, but we can also think positively and say that perhaps it also seems to imply that this git thing is working out and not slowing people down.
Anyway, I really don't want to drag out 2.6.13 as long as 2.6.12 took, and we don't have any reason to anyway, so let's try to see if we can calm things down again, and people who are thinking about writing new code might think about spending some quality time looking at the existing code and patches instead.
Now, that big patch ends up being spread out over 2069 commits, and a noticeable chunk of it is actually the new xtensa architecture that got merged, but that still leaves a lot of patches all over the place (things like a few new console fonts, for example ;). The shortlog is over 100kB in size, which means that I think linux-kernel won't take it if I include it here, so I won't. Similarly, the diffstat is 200kB, partly because of the spread out nature of the pacthes.
ARM, x86[-64], ppc, sparc updates, networking, sound, infiniband, input layer, ISDN, MD, DVB, V4L, network drivers, pcmcia, isofs, jfs, nfs, xfs, knfsd.. You name it.
Git trees and traditional patches/tar-balls are out there, or at least slowly mirroring out.
Bill Davidsen remarked:
Can't comment on git slowing things down, but I have to think that the time it took, and was ALLOWED to take, is a result of the -stable fixes working very well indeed. The fact that the 2.6.11.X was available to take the presure off to get something out of the door.
My big thank you to the stable folks, I personally think this idea is working as intended.
12. Linux 220.127.116.11 Released
29 Jun 2005 (2 posts) Archive Link: "Linux 18.104.22.168"
People: Chris Wright
Chris Wright announced Linux 22.214.171.124, saying:
We (the -stable team) are announcing the release of the 126.96.36.199 kernel.
The diffstat and short summary of the fixes are below.
I'll also be replying to this message with a copy of the patch between 188.8.131.52 and 184.108.40.206, as it is small enough to do so.
The updated 2.6.12.y git tree can be found at:
and can be browsed at the normal kernel.org git web browser:
13. Status Of Merging FUSE
30 Jun 2005 - 4 Jul 2005 (78 posts) Archive Link: "FUSE merging?"
Topics: FS: NFS, Security
People: Andrew Morton, Bert Hubert, Anton Altaparmakov, Miklos Szeredi
Miklos Szeredi asked about the status of merging FUSE into the mainline kernel. There started to be a bit of an argument over various ugly security aspects, but at one point Andrew Morton said:
I believe that the requirement which fuse_allow_task() attempts to satisfy is legitimate and is useful to FUSE users.
The fact that, AFAIK, nobody as found a way to implement it more nicely is a Linux problem, not a FUSE problem.
Given that the actual amount of code involved is small, centralised and well known about we can easily fix it up later if/when new infrastructure or new ideas become available.
So unless someone is able to come up with a better approach in the next few days I'm inclined to say "we suck" and merge the thing as-is.
However, a few things:
A bunch of folks started hashing out a better implementation; elsewhere, Andrew asked, "dumb question: what does FUSE offer over simply using NFS protocol to talk to the userspace filesystem driver?" Bert Hubert replied, "NFS currently does not currently engender warm feelings wrt ease of programming and quality in general - especially under Linux sadly enough. It is also a narrow window through which to speak to the rich set of options, flags, attributes and features the Linux kernel offers. I think Solaris used to implement bind mounts through loopback NFS, but that went out of fashion as well."
Miklos also started listing benefits, but at one point Andrew remarked, "Sorry, but I'm not buying it. I still don't see a solid reason why all this could not be done with nfs/v9fs, some kernel tweaks and the rest in userspace. It would take some effort, but that effort would end up strengthening existing kernel capabilities rather than adding brand new things, which is good." Anton Altaparmakov replied:
FUSE is a generic FS API which is _very_ easy to write an FS for (learning curve is about 10-15 minutes starting after you have unpacked the fuse source code, at least it took me that long to start writing an FS based on the example one provided). NFS is not anything like that.
Also can the NFS approach provide me with different content depending on the uid of the accessing process? With FUSE that is easy as pie. Even easier than that actually...
He added in a subsequent post:
I forgot: And doesn't NFS require stable inode numbers and other "invariables" like that for it to work? FUSE doesn't and those requirements are a real PITA in a lot of cases where there simply are no inodes and the numbers are synthetic and change on each remount or even on each access after the dentry has expired...
And I always thought that doing FS in userspace via NFS is considered an ugly hack. I didn't have the impression that that had changed recently. (-;
The discussion did not result in any concrete yay or nay on FUSE.
14. Linux 2.6.13-rc1-mm1 Released
1 Jul 2005 - 4 Jul 2005 (23 posts) Archive Link: "2.6.13-rc1-mm1"
Topics: Bug Tracking, Kernel Release Announcement, Power Management: ACPI
People: 2.6.13-rc1-mm1, Andrew Morton
Andrew Morton announced Linux 2.6.13-rc1-mm1, saying:
15. Linux 2.4.32-pre1 Released
4 Jul 2005 (1 post) Archive Link: "Linux 2.4.32-pre1"
People: Marcelo Tosatti
Marcelo Tosatti announced Linux 2.4.32-pre1, saying:
Here goes the first -pre of v2.4.32.
It contains a small amount of fixes, most notably x86_64 security updates.
Check for canonical addresses in ptrace (CAN-2005-1762)
Fix canonical checking for segment registers in ptrace (CAN-2005-0756)
Fix buffer overflow in 32bit execve on x86-64/ia64 (CAN-2005-1768)
16. Linux 2.6.13-rc2 Released
5 Jul 2005 - 6 Jul 2005 (33 posts) Archive Link: "Linux 2.6.13-rc2"
Topics: Compression, Kernel Release Announcement, SMP
People: Linus Torvalds
Linus Torvalds announced Linux 2.6.13-rc2, saying:
Ok, -rc2 is pretty small, with the bulk of the diff being some defconfig updates, and cleanup of xtensa (notably removal of another copy of zlib).
But there are ia64/arm/ppc64 updates and the TSO update from Davem is probably worth pointing out to people. And various smaller things which are more easily just seen from the shortlog.
Among the one-liners of note is the silly block level spinlock bugfix that obviously hit -rc1 and made itself felt on SMP and preempt under moderate IO loads.
17. SecurityFS Generic Security Filesystem For Security Modules
6 Jul 2005 - 7 Jul 2005 (6 posts) Archive Link: "[PATCH] add securityfs for all LSMs to use"
Topics: FS: sysfs
People: Greg KH, Mike Waychison
Greg KH said, "Here's a small patch against 2.6.13-rc2 that adds securityfs, a virtual fs that all LSMs can use instead of creating their own. The fs should be mounted at /sys/kernel/security, and the fs creates that mount point. This will make the LSB people happy that we aren't creating a new /my_lsm_fs directory in the root for every different LSM." Mike Waychison asked, "How are LSM modules supposed to use these files? or is that forthcoming?" Greg replied, "It's up to them to use it. See the patches from Serge that convert seclvl to use it instead of sysfs."
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.