Messages in this thread | | | Date | Tue, 7 Jan 1997 19:42:43 -0600 | From | (Todd T. Fries) | Subject | Re: what is wrong with this? |
| |
Andrew E. Mileski writes: > Try reading the man pages :-) I did. I tried using ioperm but no avail in my experience (regardless what any man page has told me) ioperm will return -EINVAL for anything above 0x3ff. I looked at svgatextmode and noticed an algorithm that basically went like this:
if ( port < 0x400 ) ioperm(port,len,1); else iopl(3);
Now, of course, it had error checking, and all, but that was the important parts. I scratched my head as to why what I was trying to do didn't work.
I had two fundamental problems with my approach.
1) a pointer into VIRTUAL MEMORY will never reach ioports.
2) gcc -O is imperative for outb/inb/outw/...etc to compile. initially I gave up on these because I couldn't compile without getting bad symbol references
> You cannot access ports > 0x3ff without calling ioperm(). > The iopl() man pages refer you to ioperm() for a reason.
not in my experience. Simply put, the correct version of the code that would not work is:
#include <unistd.h> #include <asm/io.h> int main(void) { iopl(3); outb(0,0x8370); }
> Explanation: A bit map is used to specify what ports a process > can access. By default, only the first 1024 are mapped since they > are commonly used. This mapping requires 128 bytes! Now it is a waste > to lug around any more if they are not being used - it takes 8k to > map the entire I/O space. > > Note: Both iopl() and ioperm() should be defined using <unistd.h> > for "portability" (if the man pages are correct).
Exactly. Except iopl(3), in addition to raising the bitmap to take 8k, sets it to allow access to any ioport, thus ioperm is not necessary when iopl is called. Or so that is the current behavior. I know not if it is correct behavior.
-- Todd T. Fries .. friest@acm.org
| |