lkml.org 
[lkml]   [2009]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/1] vfs: umount_begin BKL pushdown v2
    On Fri, Apr 24, 2009 at 01:50:25PM -0400, Christoph Hellwig wrote:

    > Having a working tree for debugging stuff is fine, but the point is
    > that it should never be pulled into mainline and probably frequently
    > reabsed to avoid cruft. In that case there's really no point in
    > creating branches to share pieces of tree history, just apply the patch
    > locally if you think you want it and merge or rebase once mainline gets
    > the patch.
    >
    > Al frequently rebases the vfs tree, btw - so even if it was a separate
    > branch now there's a fair chance it would end up in mainline with a
    > different commit id.

    Nah, it's not that. I can hold that in a separate branch and keep it
    anchored. The question is, what else will end up there?
    * the work inside the methods on BKL _removal_
    * things like merging that ->write_super() call into ->put_super(),
    etc.
    * probably parts of work on s_flags mess and ro (tied to remout)

    I agree that getting rid of BKL in that area is a good thing; no arguments
    about that. If it had been entirely self-contained, I'd gladly drop that
    stuff into a separate branch, let mingo pull it and forgot about the entire
    thing.

    The things get tricky, though, since we have two more things in the same
    area: remount (once Nick comes back with the latest on mnt_write_count,
    I'm going to merge that and start on per-sb side, BTW) and stuff around
    Jan's sync series.

    So let's figure out how do we do that. I have no problem with a single
    branch for *all* of that, separate from the rest of VFS stuff. However,
    I very much suspect that it's not what mingo et.al. have in mind - too
    much stuff alien for them. I can keep a cherry-picked branch with minimal
    BKL-affecting backports from that one. It might or might not be OK,
    depending on what the hell their workflow is in -tip. I honestly have
    no idea how the devil the things are done there, except that it apparently
    involves much more merges than I'd be comfortable with, but then I never
    had a taste for literal clusterf*cks either.

    Could the folks from the other side tell
    * what kind of patches do they want in that branch
    * what kind of patches can they accept in that branch
    * when do they intend to see it merged into mainline
    * how much is going to be merged on top of that and how often
    (if ever) is it going to be thrown out and re-pulled. I.e. is that for
    a devel/debugging tree pulled together from many topic branches on
    regular basis, with branches dropped/re-added/etc. (i.e. something a-la
    linux-next) or is that something more cast in stone?

    Seriously, let's sort that out; flamefests being what they are, there's
    a real problem with keeping two streams of development tolerable for
    participants. I *do* have very unkind words to say to Ingo, but that's
    a matter for private mail and I'm not going to let that anywhere near
    development question.


    \
     
     \ /
      Last update: 2009-04-24 20:59    [W:0.028 / U:30.048 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site