lkml.org 
[lkml]   [1996]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: SVGA kernel chipset drivers.
Date
Quoth Kenneth Albanowski:
>
> On Thu, 6 Jun 1996, Systemkennung Linux wrote:
>
> > > > 2. Speed, lots calls to ioperm()/iopl() can't be good for
> > > > performance
> >
> > A single call to ioperm()/iopl() isn't good for portability.
>
> Here's an idea: how about a _small_ kernel driver that mediates access to
> the range of I/O ports likely to be used by the video card? Only one
> device could open the driver at a time (that stops two processes from
> grabbing the screen at the same time) and simple read/writes could read
> and write to I/O ports in the specified range. (Maybe a write of 4 bytes
> means output second word to the I/O port named by the first word.)

Writing control information to a device driver is slow. ioctl's are a bit
faster, but the overhead for using them for individual port operations is
still rather flakey. Plus, the kernel _can't_ easily control any ports
above 0x3ff without some serious modification to the task tables, without
checking a table manually to find out who should get what.

> _Everything_ else would go into user-space. All the kernel does is provide
> access to the I/O ports in question and keeps more then one program from
> using them at a time.

Okay, that _might_ handle security, if you have a daemon of some sort that
sits there and monitors those port accesses. It certainly does not address
performance (made even worse by the fact that the programs now talk to a
daemon, which now lessens the burden for security on the device driver), the
ability of any schmoe to cat something evil into /dev/ioports, the need for
the graphics-using program to be setuid root (at least partially) to get
access to /dev/ioports, cards that has resources outside the "likely"
address space, or multiple VC's _at all_.

Perhaps if somehow one could put minimal support for restoring textmode into
the kernel, and pass lists of ioport accesses to ioctl (perhaps even
imparting some intelligence for waiting on bits/values or skipping/jumping,
a la the Amiga copper), it might be viable.

No need for this to be in the kernel; a simple daemon with iopl() could do
it as badly (and, with a different design, could do it better).

> --
> Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

-jhp

--
Jon Pickard * 149 Olive #45 * Paso Robles CA 93446 * +1 805 2399518 * 6372F5B9
-> I don't work for Concentric, but I don't work against them either. <-
"Unix is user-friendly; it's just very particular which users it's friendly
with."


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.075 / U:3.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site