Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!sdd.hp.com!nigel.msen.com!math.fu-berlin.de!irz401!sax!not-for-mail
From: joerg@sax.sax.de (Joerg Wunsch)
Newsgroups: comp.os.386bsd.development
Subject: Re: /dev/mem and /sys/i386/i386/mem.c
Date: 11 Jun 1993 21:10:07 +0200
Organization: SaxNet, Dresden, Germany
Lines: 25
Distribution: world
Message-ID: <1valaf$i22@sax.sax.de>
References: <1993May28.222533.24315@ucsu.Colorado.EDU> <1u8a8u$o8m@wzv.win.tue.nl>
NNTP-Posting-Host: sax.sax.de
In article <1u8a8u$o8m@wzv.win.tue.nl> guido@gvr.win.tue.nl (Guido van Rooij) writes:
>done in kernel. With a proper interface for setting the bitmap in the TSS
>(i.e. specifying, per process, which ports are allowed to read/write),
>you can do the inb/outb's in user mode, and is thus much cheaper.
Guido, we've had a discussion in the console device driver group,
with David Wexelblat from XFree86 listening. The idea of using the i/o
permission map seems to be reasonable only for the first moment. As
long as you gonna support only ports up to 0x3ff it's okay. But some recent
super VGA cards are using the 16-bit io address space as well, and
supporting that on an io perm bitmap basis would heavily increase
the TSS struct. [dwex thus said, they have been very happy on SVR's,
there's just a call to enable all i/o.] Enabling *any* i/o to a
user process is done for the X server, but for security reasons, this
should be restricted to suid-root processes. [And since everyone is
trusting the kernel, why not trusting a suid-root proc?] On the other
hand, providing some slow mechanism via the /dev/io... interface may
suffice for several applications where performance doesn't matter.
J"org
--
J"org Wunsch, ham: dl8dtl : joerg_wunsch@uriah.sax.de
If anything can go wrong... : ...or:
.o .o : joerg@sax.de,wutcd@hadrian.hrz.tu-chemnitz.de,
<_ ... IT WILL! : joerg_wunsch@tcd-dresden.de