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 [email protected] > 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 [email protected] | PGP key: wwwkeys.pgp.net
Attachment:
signature.asc
Description: Digital signature
- References:
- -mm -> 2.6.13 merge status
- From: Andrew Morton <[email protected]>
- -mm -> 2.6.13 merge status
- Prev by Date: Re: Linux-2.6.12
- Next by Date: git-pull-script on my linus tree fails..
- Previous by thread: Re: -mm -> 2.6.13 merge status (fuse)
- Next by thread: Re: -mm -> 2.6.13 merge status
- Index(es):
 |