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
    Andrew Morton wrote:
    > git-ocfs
    >
    > The OCFS2 filesystem. OK by me, although I'm not sure it's had enough
    > review.

    Every time I come up with a complaint about ocfs2, the Oracle guys
    manage to shoot me down. I think it's OK to merge.


    > 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


    > rapidio-*
    >
    > Will merge.

    send through netdev, as is proper


    > dlm-*.patch: Red Hat distributed lock manager
    >
    > Hard. Right now it seems that no in-kernel projects will use this and
    > only one out-of-kernel project will use it. Shelve the problem until
    > after Kernel Summit, where some light may be shed.
    >
    > Opinions are sought...

    I hate to say it, since its my own employer, but I agree: wait for
    in-kernel users, at the very least.


    > 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


    > inotify
    >
    > There are still concerns about the userspace API and internal
    > implementation details. More slogging needed.

    We should ask hpa what he needs for kernel.org. Ideally kernel.org
    probably wants <something> that facilitates listening to <something> for
    a list of files being changed. That would greatly speed up the robots,
    and possibly rsync-like activities too.


    > 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.


    > 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.


    > 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, and indeed vendors ARE shipping
    other crashdump methods.


    > 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.


    > v9fs
    >
    > I'm not sure that this has a sufficiently high
    > usefulness-to-maintenance-cost ratio.

    agreed (though I think 9P is neat)


    > It has been said that a userspace NFS server can be used to get
    > full NFS server functionality with FUSE. I think the half-assed kernel
    > implementation should be done away with.

    "It has been said" -- its true. A userspace NFS server can do 100% of
    userspace FS functionality.

    Jeff


    -
    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 17:38    [W:0.028 / U:1.676 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site