lkml.org 
[lkml]   [1999]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: New resources - pls, explain :-(
    Linus Torvalds <torvalds@transmeta.com> wrote:

    > But the whole discussion started as a _byte_ order discussion. And I still
    > do not agree with _any_ of those arguments. I will not call it
    > "writel_na()", because I still do not agree at all with the concept of
    > making the IO thing byte-order-dependent.

    OK.

    What I think would be useful is to have an insl_bytes as well as insl
    (and outsl_bytes, insw_bytes, outsw_bytes). The idea of insl_bytes is
    that a driver uses it when it is actually inputting an array of bytes
    as opposed to an array of 32-bit quantities, but doing it 4 bytes per
    access.

    This (or something like it) would reduce the #ifdefs in quite a few
    drivers.

    The ins/outs macros are the ones which most need to make this
    distinction since they go directly between the I/O port and memory,
    and you don't get the chance to put in explicit endianness conversion
    on the way.

    Another approach which might work is to have insw decide (on
    big-endian platforms) whether to byte-swap or not depending on the
    type of the argument it's given, like this:

    #define insl(port, buf, nl) do { \
    switch (sizeof(buf[0])) { \
    case 1: \
    __insl_ns((port), (buf), (nl)); \
    break; \
    case 4: \
    __insl(((port), (buf), (nl)); \
    break; \
    default: \
    __insl_bad(); \
    } \
    } while (0)

    Comments, anyone?

    Paul.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:53    [W:5.678 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site