Re: -mm -> 2.6.13 merge status

From: Andrew Morton (akpm_at_osdl.org)
Date: 06/21/05

  • Next message: Christoph Hellwig: "Re: -mm -> 2.6.13 merge status" 
    Date:	Tue, 21 Jun 2005 13:22:04 -0700
To: Jeff Garzik <jgarzik@pobox.com>

    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/

  • Next message: Christoph Hellwig: "Re: -mm -> 2.6.13 merge status"

    Relevant Pages

    • Re: -mm -> 2.6.13 merge status
      ... | other crashdump methods. ... This is not a filesystem but a filesystem + ... IMO considered in that light, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: silent semantic changes with reiser4
      ... > Marketed product: a set of hooks, the wider the better, no matter how ... remove these features and make it a "normal" filesystem. ... you changed into a meta directory using ftp and some manage to break ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: silent semantic changes with reiser4
      ... on a sufficiently fast box; don't work when there are ... Remember that the Solaris attribute model is just another filesystem ... inodes that delete themselves when other inodes are changed creep me ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: -mm -> 2.6.13 merge status (Suspend-to-disk)
      ... > infrastructure which some power management patches need, ... > mean that the success rate for crashing kernels is not high enough for ... > kdump to be considered a success. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: First impressions of reiserfs4
      ... the sys_statfs64API is broken such that the filesystem can't make ... we can't be guaranteed to fit into the 32-bit f_blocks counts ... Andreas Dilger ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)