"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
> > 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.