Date: Sat, 20 Dec 1997 04:52:10 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, hasty@rah.star-gate.com Cc: current@freebsd.org, gjp@erols.com, gjp@erols.net, pb@fasterix.freenix.org Subject: Re: cvs commit: src/sys/i386/linux linux.h linux_ioctl.c Message-ID: <199712191752.EAA21467@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>I know what ioperm does and I first implemented it for 386bsd 0.0 8) That was more like Linux iopl than Linux ioperm. Linux iopl is already implemented (incorrectly) in the Linux emulator. In Linux, it sets the iopl bitfield to the specified value (0-3). In the Linux emulator, it always sets the iopl bitfield to 3. >Not sure if it is worth any hazzle to implement it the way that >that svgalib uses it . The problem comes in when they want to There is no choice. Anything else would not be Linux compatible. >do any kind of video acceleration how to then enable all those >i/o registers for something like an S3 chipset. Svgalib presumably uses iopl for the hard cases. Linux has a restriction on the bitmap size, at least in old versions, so it may be impossible to access all the registers using ioperm. FreeBSD VM86-ioperm doesn't have this restriction. >At any rate, there may be other valid uses for ioperm other than >for svgalib. Linux ioperm gives some chance of secure access to device registers. It needs at least a big immutable database of which registers are secure. Where are all those i/o registers in your graphics card today? Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712191752.EAA21467>