lkml.org 
[lkml]   [2005]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: -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/

    \
     
     \ /
      Last update: 2005-06-21 22:37    [W:4.224 / U:0.252 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site