I have looked at the SVGAlib code and some of the kernel code.
As far as I can tell, SVGAlib (writers) have thought about my
problem, but I cannot see if they have resolved/bypassed it.
As far as I can see, iopl() is not yet implemented, although
there is a complicated routine in arch/i386/kernel/ioport.c
called sys_iopl(lots'o'args) that doesn't seem to be used
anywhere yet.
Has anyone already tried a kernel patch to:
1) kludge ioperm (etc.) to provide the extra 8k bitmaps?
or 2) implement iopl that is accessible from userspace?
OR
is there a standard trick that you device driver experts
recommend? (Should mmap'ing /dev/port work? or has this
got lots of overhead? or is it still restricted to < 0x3FF?)
I agree with comments in the kernel code that 8k per process for IOport
bitmaps is excessive, so changing IO_BITMAP_SIZE and recompiling the
kernel is not the "right" solution (although possibly the most
expedient).
Even you cannot provide a definitive answer,
feel free to correct my questions or share how you have(/would)
solve my little problem. It might be nice to know how things
change when writing a kernel driver.
Thanks, Erik (Heh, I'm a chemist, not a computer wiz!-)