Re: Should /dev/kmem support above 0x80000000 area?

[Jun Sun <jsun@mvista.com>]

"Maciej W. Rozycki" wrote:
> 
> On Mon, 11 Dec 2000, Jun Sun wrote:
> 
> > I see.  It is funny that you cannot read/write memory beyond high_memory
> > through /dev/mem, but you can re-map it and then read/write through the
> > remapped region.
> 
>  I see it consistent.  The system memory can be treated like a stream of
> bytes.  That's much like any random-access file.  Other devices do not
> necessarily exhibit this behaviour.  They may implement side effects,
> values read may be different from what was written previously.  You may
> even achieve different effects by performing transfers of different
> widths.
> 
> > How do you control the width of bus transfers?  If you have direct access to
> > the device memory, the userland "drivers" should be able to deal with the bus
> > access width correctly.
> 
>  If you declare a location int32_t, gcc will perform a 32-bit access on
> assignment (lw/sw for MIPS).  If you declare a location int16_t, gcc will
> perform a 16-bit access (lh/sh for MIPS).  Ditto for int8_t (and for
> int64_t for 64-bit configurations).  Names of types do not matter, of
> course, sizeof -- does.  I just used the ISO C portable names for
> fixed-size types.  Please note you might need to use the "volatile"
> keyword or gcc might reorder or even optimize out certain accesses.
> 

I see the point now.  It is not such a good idea to map IO memory through a
file API, especially given that we have a working /dev/mem.

Ralf, I "officially" retract my previous patch.

Jun