"Maciej W. Rozycki" wrote: > > On Mon, 11 Dec 2000, Jun Sun wrote: > > > I am surprised. I thought /dev/mem is for accessing SYSTEM RAM. (do a 'man' > > You access the memory space. Whatever is found at the address you > specify, be it RAM, an MMIO area or unoccupied space. You may receive a > bus error in the latter case (depending on a system configuration). > > > on /dev/mem) It is also confirmed by the code in drivers/char/mem.c. If you > > want to access anything beyond 'high_memory", nothing is read. > > Yep, you may only use read()/write() for system RAM. For other areas you > have to mmap() the interesting part of /dev/mem and then access it > directly (which is easier and better anyway, as you may control the width > of bus transfers -- not all MMIO devices support all widths). > 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. 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. > > That reason I want to fix /dev/kmem is that in some cases before a driver is > > written people want to play with the hardware directly from the userland > > (especially for demo purpose. :-0) Very useful for embedded systems. > > I'm not sure how to use /dev/kmem for this purpose -- it's kernel's > *virtual* memory... > kseg0 and kseg1 are part of kernel virtual memory space. If we implement /dev/kmem correctly, one should be able to directly read/write those area by specifying 0x80000000 or 0xa0000000 offsets through /dev/kmem. Jun
