On Thu, 17 Oct 2002, Stas Sergeev wrote: > Bart Oldeman wrote: > >> slower than xdos... why ioperm() doesn't allow > >>>0x3ff ports?.. > > Once upon a time Linus decided that a 128 byte per-process i/o bitmap > > is ok, but 8192 bytes is excessively large. > Yes, and there was a reason then, which was > that ISA had 10-bit IO space most likely, but > why it wasn't altered since, is still unclear. > > > see also iopl(2)
(I meant the man page, which has this explanation about ioperm too) > I don't think it can be used. Even if I trap > int10, do iopl(3), then trap iret and do iopl(0), > it is still dangerous, because pesky vbios calls > some other ints in a mean time. I'm sure it cannot be used to get fast port access. CLI and STI are no longer virtualized (very dangerous - this can crash the machine) and moreover inside V86 mode the IOPL setting is ignored for "IN" and "OUT". The only way to get around this is to hack the kernel to have 8k/process IO bitmaps. Searching lkml I found out that Ingo Molnar attempted (in 1998) to get ioperm bitmaps allocated on the fly (only if the app tries to do ioperm()) but he said it was very difficult. Bart - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
