[lkml]   [2010]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT PULL v2] Preparation for BKL'ed ioctl removal
    On Monday 26 April 2010, Ingo Molnar wrote:
    > This could be done all automated for a hundred old drivers if need to be.
    > There would be no bkl_ioctl's left.

    I don't think it can be fully automated. For the majority of the modules,
    your approach would work fine, but there are still the well-known
    pitfalls in corner cases:

    - recursive uses in functions outside of ioctl (possibly none left
    after the TTY layer is done, but who knows)
    - lock-order problems with other mutexes (see DRM)
    - code that depends on autorelease to allow one ioctl while another
    is sleeping. (a small number of drivers)

    Semi-automated should be fine though. These rules are relatively
    easy to check, so we can mass-convert all the trivial cases.

    Examples for nontrivial modules are mostly file systems, see ncpfs,
    afs, hpfs, ...

    > That, even if it looks somewhat coarse is still better than having _yet
    > another_ 'temporary transition'. The Big Kernel Lock was supposed to be
    > transitionary to begin with. It's been 10+ years and counting :-)

    I think the immediate goal should be to get the BKL out of everthing
    that's either used by real people or that's reasonably easy to do.
    We have patches for almost all of these now [1], and I've been running
    a kernel with CONFIG_BKL=n for a few weeks now. As we progress
    through the remaining modules, an increasing number of systems can
    run without this.

    I see the next steps as:
    1. make it possible to build a kernel without BKL, by removing the BKL
    from all core components for good, and making all users depend on
    CONFIG_BKL. Make it default y and put it under CONFIG_DEBUG.

    2. Remove the BKL from all modules that are either easy to convert
    to a private mutex or that are relevant to real users (e.g.
    definitely DRM, but maybe not hpfs).

    3. Change CONFIG_BKL to "default n, depends on DEPRECATED"

    4. Remove the remaining modules that nobody knows how to fix
    or cares about. Possibly the number of modules here is close
    to zero.

    5. Remove the implementation of the BKL, since no users are left.

    Getting stage 1 done for 2.6.36 or even 2.6.35 should be possible but
    still needs a lot of work. I think we should focus on that for now
    and then see how much is left to do for the other stages.

    This is still a temporary transition, but since we can't do all at
    once, I don't see better way.



     \ /
      Last update: 2010-04-26 13:31    [W:0.023 / U:2.732 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site