[lkml]   [2006]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.18 Headers - Long
    From: Kyle Moffett <>
    Date: Sun, 16 Jul 2006 08:34:53 -0400

    > Both of which may be easily cut and pasted into your GPL programs
    > with little or no effort (Hint: I do this all the time). Those are
    > so stable you don't even have to maintain it! IMHO, what you really
    > want, though, is for GCC to export a library of ASM intrinsics (like
    > memory barriers, atomic ops, etc), that are available on your current
    > architecture. If there is no __gcc_atomic_inc then it wouldn't
    > #define it and you can just go back to pthread_mutex_lock/unlock for
    > protecting an atomic variable. Such a library layer certainly
    > doesn't belong in the kernel, although if GCC got such a library
    > right the kernel might start to use it (although only the most recent
    > GCC would support it so it wouldn't be very useful).

    I agree with your assertions that the stuff in asm/atomic.h should be
    steered away from, since they generally are not expected to work in
    userspace. In fact, if you try to use the 32-bit sparc or parisc
    ones, it simply won't link because the implementations are external
    and use a hash table spinlock scheme which is in the kernel image.

    However, the pthread based locking is bad if you want to recover
    from arbitrary signals correctly. I ran into this problem while
    trying to get Linux/Sparc Mono working well.

    When people want atomic cmpxchg or atomic increment/decrement, they
    want a true atomic. This means either finish the whole thing, or
    leave no trace of the atomic having started in the first place.
    Spinlock based atomic implementations, which is what a lot of
    platforms lacking true atomic use, absolutely cannot reasonably
    provide this semantic.
    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: 2006-07-17 03:25    [W:0.037 / U:45.900 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site