Re: -mm -> 2.6.13 merge status

[Andrew Morton]

Jeff Garzik <jgarzik@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/