Jeff Garzik <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
