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

    Linus> I think we'll just define "readl()" to to be little-endian, and
    Linus> then that problem is gone. That takes care of 99% of the market
    Linus> right now, so it makes sense to just call it readl() - and let
    Linus> the 1% then have to type four extra characters for
    Linus> "vme_readl()" etc.

    I know you have heard this before.

    Having a readl_na() would make sense on big endian machines with PCI
    busses since since some PCI cards (some gfx and network cards) will do
    the translation for you in hardware making it look like the card is
    native byte order. For 16 and 24 bit graphics for instance it is
    absolutely not fun doing the byte swapping in software.

    I do not want a readl_bigendian() for PCI since the result would be
    that programmers would end up doing this to get a round it:

    #ifdef BIG_ENDIAN
    #define my_readl() readl_bigendian()
    #else
    #define my_readl() readl()
    #endif

    for every driver where big endian access makes sense which is pretty
    silly IMHO.

    I do not disagree with your vme_readl() proposal. Well it would be
    nice if one could have a readl() that works for everybody but if one
    wants to support 256 PCI busses in a box it might be a little
    problematic.

    Jes

    -
    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:4.439 / U:0.136 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site