[lkml]   [2005]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject-mm -> 2.6.13 merge status

    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)


    The OCFS2 filesystem. OK by me, although I'm not sure it's had enough


    OK by me for a merge. Need to poke arch maintainers first, check that
    they've looked at it sufficiently closely.


    Needs some convincing benchmark numbers to back it up. Otherwise OK.


    Tricky. Addresses vm area fragmentation issues due to recent
    optimisations to the free-area lookup code. Will merge.


    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)


    Will merge. I have a comment "The below break x440". Maybe it got
    fixed. We'll doubtless hear if not.


    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.


    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.


    SMP speedups for the core timer code. It was bumpy, but this seems
    stable now. Will merge.


    Will merge


    Will merge.


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


    Nice idea IMO, but there are still questions around the
    implementation. More dialogue needed ;)


    OK, but needs connector.


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


    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.


    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.


    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

    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.


    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.


    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?


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


    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.


    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-06-21 11:36    [W:0.027 / U:11.308 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site