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