[lkml]   [1999]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: New resources - pls, explain :-(

    On Sat, 14 Aug 1999, Pavel Machek wrote:
    > >
    > > - writel() - strict ordering
    > > - __writel() - only to be used for people who REALLY know that they don't
    > > care about ordering.
    > Please please, don't let '__' make the difference. writel_noorder
    > seems better.

    Note that the Linux internal convention has always been to have the __
    mean that it's somehow a more "basic" function.

    For example, __writel() might mean more than "no re-ordering". It might
    mean "naked IO access" - which would include the fact that it does not do
    any byte swapping etc, for example (just to tie this in with the original
    discussion). Think of it as the conceptual basis for the "real" writel(),
    that people can use when they want to build up their own IO primitives
    from the basic blocks.

    I don't mind giving people building blocks - I much _prefer_ letting
    people access the infrastructure than trying to build up some magic "good
    interface" thing, for example. Abstraction only gets you so far..

    So a __writel() thing would be equivalent to __put_user(): the same way
    that __put_user() only does the actual physical user mode access,
    __writel() would only do the actual physical PCI/MCA/whatever access.
    Anybody who uses __put_user() needs to be extra careful and guarantee that
    he has already done all the security checks - and anybody using __writel()
    needs to make sure that he does the re-ordering and byte order stuff at a
    higher level.

    The fundamental thing I dislike about "writel_be()" or something like that
    is that I don't much see the point. "Bigendian" doesn't buy you anything
    at all, and would always be conditionalized on what the CPU endianness is.
    In contrast, I _do_ see the point in something like "raw access". It makes
    sense on a conceptual level.

    It seems to me that at least the fbcon people want more than just to avoid
    byte swapping: wat they fundamentally want is not non-byte-swapped data,
    they really fundamentally want control at a very low level. I bet they'd
    be happy with not just avoiding the byte swap, but also avoiding the
    ordering constraints (or at least controlling them on a higher level).

    So __writel() would probably fit their needs better too than any
    "big-endian" or "native-endian" thing - because it really fundamentally is
    about direct access rather than about endianness.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:53    [W:0.022 / U:3.104 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site