From owner-freebsd-hackers Sun Dec 31 02:58:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA20887 for hackers-outgoing; Sun, 31 Dec 1995 02:58:45 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA20877 for ; Sun, 31 Dec 1995 02:58:38 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA27229; Sun, 31 Dec 1995 21:58:06 +1100 Date: Sun, 31 Dec 1995 21:58:06 +1100 From: Bruce Evans Message-Id: <199512311058.VAA27229@godzilla.zeta.org.au> To: freebsd-hackers@freebsd.org, j@uriah.heep.sax.de Subject: Re: /dev/io Sender: owner-hackers@freebsd.org Precedence: bulk >> The KDENABIO ioctl originates in SYSV, although in SYSV it is used >> to enable ports set in an IO permission bitmap. Most X servers need >> ports beyond the 0-0x3ff usually covered by such a bitmap. Also there >> is a performance penalty in using the bitmap. >In particular, it would require us to use CPU task switching. I >believe FreeBSD's context switching behaviour has been fine-tuned to >be better without separate task state segments per process. The extra context switching overhead would probably be acceptable if the TSS is only switched when necessary. Ordinary tasks could use the current TSS and X could use a separate TSS with a 64K bits (or whatever is necessary) bitmap. The performance penalty per i/o is less acceptable: cycles for outb %al,%dx for CPL <= IOPL (current case) / CPL > IOPL (bitmap case): 386 486 586 5 / 25 10 / 30 9 / 26 Thus even if the hardware is infinitely fast, in the bitmap case, outb on a 586 is up to 52 times as slow as most integer instructions. In the insecure case it is only up to 18 times slower :-]. Bruce