Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!ames!uhccux!munnari.oz.au!metro!news
From: glenn@extro.ucc.su.OZ.AU (Glenn Geers)
Newsgroups: comp.unix.xenix
Subject: Re: user doing direct I/O
Message-ID: <1990Jul26.232311.21450@metro.ucc.su.OZ.AU>
Date: 26 Jul 90 23:23:11 GMT
References: <251@carssdf.UUCP>
Sender: news@metro.ucc.su.OZ.AU (news)
Organization: Uni Computing Service, Uni of Sydney, Australia
Lines: 71

From article <251@carssdf.UUCP>, by usenet@carssdf.UUCP (John Watson):
> 
>   Is there any way for a user to do direct (INP/OUTP) io to devices
> similar to the printer port without writing a device driver?  These
> instructions normally result in a protection violation.

A lot of people would like to know how to do this. 
It turns out that it can be done on Xenix 2.2.2 and up using an ioctl. Only
root can perform the call and so programs which use it must be set uid 0.
The primary application is graphics - the ioctl is part of the graphics
stuff in Xenix. I don't think it will work under SCO UNIX for general 
(non-graphics) i/o.

Anyway, enough waffle. Here's how to do it:

/*
** I don't claim this code does anything useful.
** Do with it what you will
** I disclaim copyright
** G. Geers
*/

#include <stdio.h>
#include <sys/machdep.h>
main()
{
	int fd;

	fd = open("/dev/null", 2); /* open a useful file */
	ioctl(fd, IOPRIVL, 1); 
/*
** Guess what?
** You've just set the i/o privelege level of the current process
** to 3. You can write anywhere in the i/o address space!
** Be *careful*. Make 100% sure you have your i/o addresses correct
** otherwise you might trash your hard disk.
*/
	write_to_port();

	ioctl(fd, IOPRIVL, 0); /* reset to normal */
}

write_to_port() should be an assembler routine using ins/outs or whatever.
I use gcc so I like to embed my assembler inside C code using asm(). That
way stack frames and returns can be done easily. Also tests can be done in C
and it is possible to assign variables to specific 386 registers. If you are 
using masm you have to do this stuff yourself.

Whenever I write/port graphics applications I produce two (#ifdef'd) versions
one which doesn't write to hardware directly and one which does. For some
applications (e.g. dvivga) high speed writing of individual pixels is not
required but for others (e.g. ghostscript) it is. So I comprimise; 
security versus speed.

DISCLAIMER
Please nnote: I have *not* used this for anything except graphics so I don't
claim that it will work. And if you trash your hard disk or do anything
else nasty I'm not responsible.

			Enjoy,
				Glenn

p.s. If anyone does have courage enough to try non-graphics applications
I'd like to hear of the results

glenn@extro.ucc.su.oz.au
--
Glenn Geers                       | "So when it's over, we're back to people.
Department of Theoretical Physics |  Just to prove that human touch can have
The University of Sydney          |  no equal."
Sydney NSW 2006 Australia         |  - Basia Trzetrzelewska, 'Prime Time TV'