mrb1@cbnewsh.ATT.COM (maurice.r.baker) (04/28/89)
Hello ---- One more question for the net: Within the confines of System V/3.2 UNIX on an AT&T 6386E, I need to read from and write to a particular range of memory locations......to be specific, 0xC6000 to 0xC63FF (they are actually on a Matrox graphics board). Short of writing a device driver which gets linked into the kernel and runs in privileged mode, is there any other way of doing the job? Spe- cifically, through /dev/mem ??? The manuals I have access to are very terse when it comes to describing much about /dev/mem. I did try an intuitive test program or two, without any luck. (The /dev/mem permissions were set to rw-rw-rw-, so that shouldn't have been a problem). Perhaps there is a neat way to do this, although the ISDG does sound an ominous note --- "Because user programs and the operating system execute in different address spaces, the I/O cannot take place directly from the device to the user program ..." Which is kind of what I feared, but it certainly is worth a try posting the question anyhow. Maybe someone can give some interesting historical view of /dev/mem, or how to use it, if nothing else. Thanks for the help on this, and previous inquiries. M. Baker homxc!mrb1 201-949-3455
plocher%sally@Sun.COM (John Plocher) (04/28/89)
+---- In <304@cbnewsh.ATT.COM> maurice.r.baker writes: | Within the confines of System V/3.2 UNIX on an AT&T 6386E, I need | to read from and write to a particular range of memory locations......to | be specific, 0xC6000 to 0xC63FF (they are actually on a Matrox graphics | board). | Short of writing a device driver which gets linked into the kernel | and runs in privileged mode, is there any other way of doing the job? Spe- +---- In general, what you MUST do if you want any speed at all out of it, is to write a device driver which maps the physical Matrox memory into a shared memory segment and provides an ioctl() to let the user program find out what the shm key is. If you do it any other way, you incur the cost of a system call for EVERY access to the board :-( This requires knowledge of how the system keeps regions and how the shared memory scheme is implemented - both very non-trivial if you don't have the Unix sources handy. Sorry, I can't provide any example code because of non-disclosure agreements. We did this same thing at Microport with SystemV/286, and I'm doing it here at Sun with the X11/NeWS ports to V/386 :-) -John Plocher