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