Re: -mm -> 2.6.13 merge status

Andrey Panin
2005-06-21T12:07:47Z

[-- Attachment #1: Type: text/plain, Size: 6529 bytes --]

On 171, 06 20, 2005 at 11:54:58 -0700, Andrew Morton wrote:
>
> This summarises my current thinking on various patches which are presently
> in -mm. I cover large things and small-but-controversial things. Anything
> which isn't covered here (and that's a lot of material) is probably a "will
> merge", unless it obviously isn't.
>
> (If you reply to this email it would be a good idea to alter the Subject:
> to reflect which feature you are discussing)
>
>
>
> git-ocfs
>
> The OCFS2 filesystem. OK by me, although I'm not sure it's had enough
> review.
>
> sparsemem
>
> OK by me for a merge. Need to poke arch maintainers first, check that
> they've looked at it sufficiently closely.
>
> vm-early-zone-reclaim
>
> Needs some convincing benchmark numbers to back it up. Otherwise OK.
>
> avoiding-mmap-fragmentation
>
> Tricky. Addresses vm area fragmentation issues due to recent
> optimisations to the free-area lookup code. Will merge.
>
> periodically-drain-non-local-pagesets
>
> Will merge
>
> pcibus_to_node and users
>
> Will merge
>
> CONFIG_HZ for x86 and ia64: changes default HZ to 250, make HZ Kconfigurable.
>
> Will merge (will switch default to 1000 Hz later if that seems necessary)
>
> dmi-*.patch
>
> Will merge. I have a comment "The below break x440". Maybe it got
> fixed. We'll doubtless hear if not.

Fixed, patch merged in -mm as dmi-move-acpi-sleep-quirk-fix.patch

http://marc.theaimsgroup.com/?l=linux-kernel&m=111829134708641&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=111832375203467&w=2

> xen-*.patch
>
> These are little cleanups and abstractions which make a Xen merge
> easier. May as well merge them.
>
> CPU hotplug for x86 and x86_64
>
> Not really useful on current hardware, but these provide
> infrastructure which some power management patches need, and it seems
> sensible to make the reference architecture support hotplug. Will merge.
>
> swsusp-on-SMP
>
> Will merge.
>
> cfq version 3
>
> Not sure. Jens seems to be setting up a few git trees. On hold.
>
> RCUification of the key management code
>
> Don't know - dhowells seemed diffident last time we discussed this.
>
> timers-fixes-improvements.patch
>
> SMP speedups for the core timer code. It was bumpy, but this seems
> stable now. Will merge.
>
> kprobes-*
>
> Will merge
>
> rapidio-*
>
> Will merge.
>
> namespace*.patch
>
> Awaiting viro ack.
>
> xtensa architecture
>
> Is xtensa now, or will it be in the future a sufficiently popular
> architecture to justify the cost of having this code in the tree?
>
> Heaven knows. Will merge.
>
> 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...
>
> 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.
>
> inotify
>
> There are still concerns about the userspace API and internal
> implementation details. More slogging needed.
>
> pcmcia-*.patch
>
> Makes the pcmcia layer generate hotplug events and deprecates cardmgr.
> Will merge.
>
> NUMA-aware slab allocator
>
> Seems stable now, but it needs some ifdef reduction work before
> merging, please.
>
> CPU scheduler
>
> Will merge some of these patches. We're still discussing which ones.
>
> perfctr
>
> Not yet, but getting closer. The PPC64 guys still need to sort out a
> few interface issues with Mikael. We might be able to fit this into
> 2.6.13 if people get a move on.
>
> 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.
>
> 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.
>
> 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?
>
> v9fs
>
> I'm not sure that this has a sufficiently high
> usefulness-to-maintenance-cost ratio.
>
> fuse
>
> This is useful, but there are, AFAIK, two issues:
>
> - We're still deadlocked over some permission-checking hacks in there
>
> - It has an NFS server implementation which only works if the
> to-be-served file happens to be in dcache.
>
> 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.
>
> execute-in-place
>
> Will merge. Have the embedded guys commented on the usefulness of
> this for execute-out-of-ROM?
>
>
>
> -
> 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/
>

--
Andrey Panin | Linux and UNIX system administrator
pazke@donpac.ru | PGP key: wwwkeys.pgp.net

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]