Messages in this thread | | | Date | Tue, 21 Jun 2005 13:22:04 -0700 | From | Andrew Morton <> | Subject | Re: -mm -> 2.6.13 merge status |
| |
Jeff Garzik <jgarzik@pobox.com> wrote: > > > sparsemem > > > > OK by me for a merge. Need to poke arch maintainers first, check that > > they've looked at it sufficiently closely. > > seems sane, though there are some whitespace niggles that should be > cleaned up >
There are? I thought I fixed most of them.
*general sigh*. I wish people would absorb CodingStyle. It's not hard, and fixing the style post-facto creates a real mess. I now have a great string of kexec patches followed by a "kexec-code-cleanup.patch" which totally buggers up the patch sequencing and really needs to be split into 18 parts and sprinkled back over the entire series.
> > rapidio-* > > > > Will merge. > > send through netdev, as is proper >
OK. But then the master version vanishes into the jgarzik git forest and I won't know how to get it ;)
> > connector.patch > > > > Nice idea IMO, but there are still questions around the > > implementation. More dialogue needed ;) > > > > connector-add-a-fork-connector.patch > > > > OK, but needs connector. > > I don't like connector >
How come?
> > > pcmcia-*.patch > > > > Makes the pcmcia layer generate hotplug events and deprecates cardmgr. > > Will merge. > > Testing? The goal behind the patch is certainly good, but I worry about > exposure. >
Yes, there will be a few problems I guess. But people are testing it - we know, because we've had lots of bug reports which were actually due to greg-pci breakage...
> > > cachefs > > > > This is a ton of code which knows rather a lot about pagecache > > internals. It allows the AFS client to cache file contents on a local > > blockdev. > > > > I don't think it's a justified addition for only AFS and I'd prefer to > > see it proven for NFS as well. > > > > Issues around add-page-becoming-writable-notification.patch need to > > be resolved. > > > > cachefs-for-nfs > > > > A recent addition. Needs review from NFS developers and considerably > > more testing. > > > > These things aren't looking likely for 2.6.13. > > If I could vote more than once, I would! I really like cachefs, and > have been pushing for its inclusion for a while. >
You've been using it?
> > kexec and kdump > > > > I guess we should merge these. > > > > I'm still concerned that the various device shutdown problems will > > mean that the success rate for crashing kernels is not high enough for > > kdump to be considered a success. In which case in six months time we'll > > hear rumours about vendors shipping wholly different crashdump > > implementations, which would be quite bad. > > > > But I think this has gone as far as it can go in -mm, so it's a bit of > > a punt. > > I'm not particularly pleased with these,
How come?
> and indeed vendors ARE shipping > other crashdump methods.
Which ones?
> > > reiser4 > > > > Merge it, I guess. > > > > The patches still contain all the reiser4-specific namespace > > enhancements, only it is disabled, so it is effectively dead code. Maybe > > we should ask that it actually be removed? > > The plugin stuff is crap. This is not a filesystem but a filesystem + > new layer. IMO considered in that light, it duplicates functionality > elsewhere. >
hm.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |