Re: -mm -> 2.6.13 merge status

[Jeff Garzik <jgarzik@pobox.com>]

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/