lkml.org 
[lkml]   [2007]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 1/3] powerpc: Fixup hard_irq_disable semantics
    From
    Date
    On Thu, 2007-05-10 at 09:44 +0200, Geert Uytterhoeven wrote:
    > On Thu, 10 May 2007, Benjamin Herrenschmidt wrote:
    > > This patch renames the raw hard_irq_{enable,disable} into
    > > __hard_irq_{enable,disable} and introduces a higher level
    > > hard_irq_disable() function that can be used by any code
    > > to enforce that IRQs are fully disabled, not only lazy
    > > disabled.
    >
    > Why did you rename hard_irq_enable() too?
    >
    > Isn't it more logical to have high-level hard_irq_disable() and
    > hard_irq_enable(), and a special low-level __hard_irq_disable()?

    Not really. If you see my subsequent patch, the idea is to introduce a
    single generic hard_irq_disable() which is meant to be called with
    irqs already disabled (that is within a local_irq_disable section) to
    enforce that if the arch does lazy disabling, it gets hard disabled
    at this point.

    If we start adding hard_irq_enable() we end up in a can of worms:

    - Do we want all the full set of save/restore etc... ?
    - What if somebody does hard_enable while we are soft-disabled
    -and- have been hard disabled because of a pending interrupt ?
    - What's the point ? :-)

    So overall, I want to keep the semantics as simple as they can be. Maybe
    I can even add some WARN_ON() to make sure we are in a
    local_irq_disable'd section even in the generic one instead of just a
    NOP to enfore that.

    Cheers,
    Ben.


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

    \
     
     \ /
      Last update: 2007-05-10 10:47    [W:4.153 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site