"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
