On Tue, 19 Jun 2007 13:03:24 +0100 (BST), "Maciej W. Rozycki" <macro@xxxxxxxxxxxxxx> wrote:
> That should be taken care of in glibc (or your libc of choice) -- with
> ioperm() or iopl() and then in{b,w,l}() and out{b,w,l}() as appropriate.
> Either of the two formers are used to mmap() the right area of /dev/mem
> and then the latters are used access the area with the desired width (and
> stride, if applicable -- portable code should not assume subsequent I/O
> port addresses are adjacent in the MMIO space). It has worked like this
> for other platforms for at least ten years now.
>
> Of course the function doing mmap() still has to know the CPU physical
> address of the I/O space from somewhere. For quite some time my feeling
> has been it should come from /proc/iomem, where we actually fail to
> register the I/O space, but these days sysfs is probably better (though I
> plan to have a look at /proc/iomem for the use of human beings anyway).
Oh I thought ioperm() or iopl() on archs other then x86 are all dummy
routines, but apparently that was wrong. Now I have looked some
ioperm.c in glibc and am very suprised by so many hard-coded
boardname/addresses ;)
> That still does not solve the problem of multiple independent I/O spaces,
> but I gather such configurations are very rare indeed.
I agree.
---
Atsushi Nemoto
