[comp.unix.questions] priv. problem

LAGRO_4%HWALHW5.BITNET@wiscvm.wisc.EDU (09/02/87)

                                                     Wageningen 2-august-87
    Hello,

 On 24th of July I mailed a problem to the list. Because we were not
yet properly subscribed to the list, we didn't got any answer's.
Our major problem was:

          On our Unix system (an IRONICS IV-1600/S) we use
        some add on boards for the image processing part
        we are working on. In order to access these boards,
        we map them in our virtual memoryspace with the
        PHYS-call. Here we run into our problem: In order
        to use phys, one should be a super-user....

Could any one, who gave a solution to this problem, please send it to
us again?
If some of you want to receive our previous letter (which is a little
bit more precise) pleas give us a note.

     sincerely,

        Willy Geraets.    (LAGRO_4@HWALHW5.BITNET)

jfh@killer.UUCP (The Beach Bum) (09/09/87)

In article <9111@brl-adm.ARPA>, LAGRO_4%HWALHW5.BITNET@wiscvm.wisc.EDU writes:
> 
>                                                      Wageningen 2-august-87
>     Hello,
> 
> 
>           On our Unix system (an IRONICS IV-1600/S) we use
>         some add on boards for the image processing part
>         we are working on. In order to access these boards,
>         we map them in our virtual memoryspace with the
>         PHYS-call. Here we run into our problem: In order
>         to use phys, one should be a super-user....
> 
Phys() requires you to be root so you don't map the U-page (or something
else more useful) into your address space so you can't just change your
UID to root, so in general disarming phys() is a bad idea.  Changing the
programs that access the boards to Set-UID root is about the only idea
I can come up with - that or write a device driver to read and write the
address space that is occupied by the graphics boards.

If you don't happen to have a copy of the sources to io/mem.c for the
memory device driver, they are 1). simple to write and 2). I have my own
copy I would be willing to send you.

John.
-- 
John F. Haugh II		HECI Exploration Co. Inc.
UUCP:	...!ihnp4!killer!jfh	11910 Greenville Ave, Suite 600
"Don't Have an Oil Well?"	Dallas, TX. 75243
" ... Then Buy One!"		(214) 231-0993

ron@topaz.rutgers.edu (Ron Natalie) (09/10/87)

I've never heard of an Ironics, but I agree the best way to handle
these types of boards is with a /dev/mem-like device.  For example,
I wrote software for a Datacube MinVideo board to provide a read/write/
lseek interface for the large transfers (writing the display buffers
and colormaps) and a ioctl based interface for poking individual bytes
in the scads of control registers for the board.  It took about a
days worth of editing to modify all their libraries that used phys
to use this interface (I even found a few bugs in the process).

-Ron