lkml.org 
[lkml]   [2007]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] "volatile considered harmful", take 2
    On 5/11/07, jimmy bahuleyan <knight.camelot@gmail.com> wrote:
    > Jonathan Corbet wrote:
    > [snip..]
    > > +
    > > + - The jiffies variable is special in that it can have a different value
    > > + every time it is referenced, but it can be read without any special
    > > + locking. So jiffies can be volatile, but the addition of other
    > > + variables of this type is strongly frowned upon. Jiffies is considered
    > > + to be a "stupid legacy" issue in this regard.
    >
    > Why is it that you consider jiffies to be a "stupid legacy"?

    You could find better explanations in previous threads, but to
    summarize my understanding of the matter:

    Because it is not humanly possible to audit the entire kernel tree to
    find all usages of jiffies and fix them appropriately (i.e. "stupid
    legacy reasons"). Hence, we just define jiffies as volatile.

    > Isn't it natural to have a externally modified variable which is only /read/ to
    > be volatile?

    No, even in such a case, it would have been saner to simply define the
    jiffies _without_ volatile, and only cast _accesses_ to it with the
    volatile type qualifier.

    Unfortunately, even this is not possible to do in all existing users
    in the kernel (i.e. "stupid legacy reasons").

    > (or is jiffies supposed to be replaced with something smarter/better :)

    Not _replace_ jiffies. But if it were _really_ possible to do so (i.e.
    assuming for a moment that we could change all kernel code in one
    magic sweep), then again we wouldn't need to use volatile for jiffies
    (or even use a volatile cast, IMO).

    Just ensure all accesses to jiffies are protected behind an
    appropriate barrier() instead, the effects of which are more clearly
    defined than the vague and insufficient "volatile", and which
    *guarantees* that all memory would be re-read from that point (note
    that "volatile" is merely a hint to a C compiler, it comes with no
    guarantees at all, which is particularly worrisome these days when
    compilers are not the only entities that can re-order code -- hardware
    can do so too).

    However, yet again, it is _not_ possible to fix the above for all the
    existing kernel code that uses jiffies (i.e. "stupid legacy reasons"),
    so we just define jiffies as volatile.

    My understanding, at least.
    -
    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 23:47    [W:2.526 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site