Re: What is the right type to store virtual address ?

Petr Vandrovec Ing. VTEI (VANDROVE@vc.cvut.cz)
Thu, 19 Aug 1999 20:25:46 MET-1


On 19 Aug 99 at 11:12, Linus Torvalds wrote:
> On Thu, 19 Aug 1999, Petr Vandrovec wrote:
> > if we are talking about endianess, I have one related small
> > question: in variable of which type I should store return
> > value from ioremap() ?
> It shouldn't much matter for the simple reason that the only thing you can
> do with the return value from ioremap() is to pass it in to read[bwl]()
> and friends, and they (for historical reasons) accept both a pointer and a
> integer.
It matters because of I can pass return value from ioremap() also to
memcpy_{from,to}io and check_signature. check_signature is almost dead,
but memcpy_{from,to}io (if guaranteed transfer widths) is useful on
some archs with complicated readb code. And check_signature requires
long, but memcpy_toio on sparc64 pointer.
> For _true_ cleanliness, it should probably be something like
> typedef struct {
> unsigned long base;
> } io_base_t;
> /*
> * The ISA legacy region 640kB-1M is always mapped,
> * here's the base
> */
> extern io_base_t isa_io_base;
> extern io_base_t ioremap(unsigned long addr, unsigned long len);
> extern unsigned char readb(io_base_t base, unsigned int offset);
> ...
> but while I'd potentially like to see that I also wonder about just the
> pain of doing the conversion.
I'm doing this in matroxfb (having u_int8_t* base). Unfortunately,
compiler is not happy from this sometime and adds base.base and offset
together again and again in subsequent writeb although they do not change
(and both are stored in registers, i386). On other side, you do not have
to pass address to readb - you can pass device region identification
too (if hardware does not map devices directly to physical address space).
Petr Vandrovec
vandrove@vc.cvut.cz

-
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/