[lkml]   [2004]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Fix the cpumask rewrite

    On Sat, 26 Jun 2004, James Bottomley wrote:
    > This might be correct for x86 and itanium, but it isn't for parisc where
    > our bitmap operators don't take volatile pointers.

    Why not? The thing is, the bitmap operators are supposed to work on
    volatile data, ie people are literally using them for things like

    while (test_bit(TASKLET_STATE_SCHED, &t->state));

    and the thing is supposed to work.

    Now, I personally am not a big believer in the "volatile" keyword itself,
    since I believe that anybody who expects the compiler to generate
    different code for volatiles and non-volatiles is pretty much waiting for
    a bug to happen, but there are two cases where I think it's ok:

    - in function prototypes to show that the function can take volatile data
    (and not complain).

    - as an arch-specific low-level implementation detail to avoid having to
    use inline assembly just to load a value. Ie a _data_structure_ should
    never be volatile, but it's ok to use a volatile pointer for a single

    I believe the bitop functions fall under #1 - the function is clearly
    supposed to handle the case of a volatile pointer, and if it is inlined,
    the above endless while-loop must not just load the bit once and turn it
    into an endless loop - it needs to re-load the thing every iteration.

    > Since whether the bitmap operators are volatile or not is within the
    > province of the architecture to decide,

    I disagree. Why wouldn't they be volatile?

    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: 2009-11-18 23:46    [W:0.020 / U:1.652 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site