Quoting John Kohl,

> For I/O permission bitmaps, linux has a two-tier mechanism.  If a
> program only wants to access ports below 0x3ff, then it will diddle an
> I/O bitmap in the process's TSS.  For ports above 0x3ff, the program
> must set its IOPL to 3 (that's what X11 does currently to get access to
> the video ports).

> This is nice because many I/O ports are below 0x3ff, and it doesn't
> require gobs of bitmap space in the TSS. I'm tempted to implement the
> same scheme for NetBSD/i386.

It is a reasonable scheme I guess. There is also the ioctl() interface
that SysV systems use, but that looks a bit ugly. I implemented enough
of this last weekend to have a shot at getting svgalib to work, but
unfortunately there were severe problems with that in the end. Like
the svgalib code doing an fstat() on filedesc 2, and pulling the major
dev number out of that info to determine if it was the right kind
of tty.. ugh. Needless to say, major device numbers for VTs are different
on NetBSD, so that will never work.

> And then there's the linux emulation mode stuff to consider--do we want
> to support the linux vm86 syscall interface?  If so, then the
> implementation choices of user vs. kernel code is forced.  We _could_
> easily share the code and make it available for a NetBSD vm86 interface,
> but _should_ we use the interface as it stands?

The first question is: what is the best interface? It would be very nice
if the Linux vm86 syscall could be supported using it, but I wouldn't
want to end up with a bad interface just because we want it to cooperate
with the Linux emulation. I think having vm86 as a system dependent
system call is a good choice though.

- Frank