>
>
> I don't see the big reason to get rid of iopl() in Xfree86, as Xfree does
> need IO access rights anyway. I'd rather have iopl() in X than try to be
> too clever in the kernel (and starting to virtually remap the TSS just to
> get a larger iomap area sounds like trying to be clever for the wrong
> reasons).
>
Actually I think Ingo could confirm that it turned out to be the fastest
way of implementing ioperm() bitmap switching in the softswitch patch,
which has one TSS per processor. The fact that it allows also 64k I/O
ports instead of 1024 while copying less data during task switches is a
side effect. The first version of this patch faithfully followed the
1024 port limit.
Note that the modified PTEs are only used by one processor and so
never require invalidation IPI on SMP.
The main reason it was implemenented was the following message:
(and we have shown that it is possible to implement it efficiently,
whether it's useful or not is another question)
On 28 Aug 1997, H. Peter Anvin wrote:
> Followup to:
<Pine.LNX.3.95.970827134006.2904A-100000@pc7537.hil.siemens.at>
> By author: Ingo Molnar <mingo@pc7537.hil.siemens.at>
> In newsgroup: linux.dev.kernel
> >
> > without any TSS switching, with full iopl() and ioperm() interface
> > compatibility...
> >
>
> You may wish to see if you can get rid of the 1024-port limitation in
> the ioperm() bitmap. Since so few processes use ioperm(), you may be
> able to allocate a full 64K-port bitmap once they call ioperm().
> Linus couldn't do this for memory management reasons, maybe your code
> can...
>
Gabriel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu