lkml.org 
[lkml]   [2000]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Direct access to hardware

> > > It _is_ possible. Check out "capabilities".
> >
> > Whoops, excuse me for being stupid! Should have looked closer...
> >
> > But why on earth do we have this several-hundred-postings thread on this,
> > if it is already possible to disable all the raw access?
> >
> > Is it actually feasible? Which important or often used apps do need raw
> > access?
>
> X

Actually, for X, it can be solved by fine-graining "raw io access" - I
wrote a small module for svgalib, but can be easily used for X as well,
which provides a char device similar to /dev/mem, except that it only
allows access to the range 0xa0000-0xbffff and to all ranges for PCI
regions of devices of class 0x0300 (display devices). In addition the
device has ioctls for inb/outb/inw/outw/inl/outl, which only allow
accessing range 0x3c0-0x3df and PCI regions of display cards.
Making X use this device instead of /dev/mem direct IO is simply a
matter of replacing "/dev/mem" with "/dev/svga" in the source and
changing the definition of outb/etc to do the ioctl, instead of direct
IO (except for some cards, like a few versions of the mach64 which need
other IO ports). There is no performance difference unless IO is used
for acceleration, which is only true with a few cards.

With this, X indeed will have raw access to IO, and will probably be
able to burd video card / monitor. With many cards it can also
crash/lock the system with some programming to the video card. But X (or
any process with such video access) won't be able to directly program
the IDE/SCSI controller, or any other device.


--
Matan Ziv-Av. matan@svgalib.org


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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