mats@fortune.UUCP (Mats Wichmann) (12/12/85)
Boy it's fun following discussions when only half the messages
come through...
Phys() is nonstandard. It is not included in any of the standards.
While not invented by UniSoft, they certainly had a good use for
it - the purpose is generally to allow (someone) access to hardware
without needing a driver or some other kernel help. You generally
don't want to do this on a 40-user machine, but you may well want
to do it on a binary-only single-user workstation. Thus, some
people put phys() in, and some don't.
Don't count on it being there, though.
Mats Wichmann
Fortune Systems
{ihnp4,hplabs,dual}!fortune!mats
"Quality. Comfort. Style.
And at prices jou can afford!"
- Izzy Morenojsdy@hadron.UUCP (Joseph S. D. Yao) (12/19/85)
In article <612@unisoft.UUCP> paul@unisoft.UUCP (n) writes: > Someone suggested the PHYS(2) system call for accessing physical > + >addresses from user processes. This is a Uniplus 'feature', not a System >V 'feature'. Don't expect to see it in a port done by someone other than >Unisoft. (Mind you it is a neat idea, just right for mapping in such things >as bit mapped graphics, device registers, floating point boards .....) Just to keep the record straight, it first appeared in PDP-11 UNIX, I believe V7 ["7th Edition" to revisionists], marked as one of those things that wasn't guaranteed to be kept in future releases. While Unisoft is to be given credit for making it work on other architectures and perpetuating it, they should be careful about accidentally implying that they invented it. I'm not sure whether phys(2) originated at AT&T or was adopted. (Sidebar: "maus" shared memory is also a PDP-11 V7[?] feature that was marked to disappear, and that others have picked up and perpetuated. I believe that one actually originated in Vrieje Universitat ages ago.) -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
grt@twitch.UUCP ( G.R.Tomasevich) (12/20/85)
> >addresses from user processes. This is a Uniplus 'feature', not a System > >V 'feature'. Don't expect to see it in a port done by someone other than > >Unisoft. It would be nice for phys() to become permanent. My suggestion about reading from /dev/mem and calculating the address is trivial only if the physical address space is commensurate with the number of address bits in the DMA device, such as 18 bits for PDP-11/45 and DR11W or LSI-11/23 and DRV11B, both of which we have done. If you need to access something like a Unibus map, for example, it would be a pain from user space. I am not sure one could even cook up a way to grab some Unibus map registers without some kind of 'driver'. -- George Tomasevich, ihnp4!twitch!grt AT&T Bell Laboratories, Holmdel, NJ
chris@umcp-cs.UUCP (Chris Torek) (12/24/85)
In article <264@twitch.UUCP> grt@twitch.UUCP (G.R.Tomasevich) writes: > My suggestion about reading from /dev/mem and calculating the > address is trivial only if the physical address space is commensurate > with the number of address bits in the DMA device, And if the device does not need byte transfers or something else exotic, and if on a Vax, can tolerate longword transfers (as opposed to word transfers; see /dev/kUmem). > If you need to access something like a Unibus map, for example, > it would be a pain from user space. kUmem in 4BSD does not go through the Unibus maps for you; it is just kmem with word transfers. This is necessary anyway on Vaxen since there can be multiple UBAs. On Vaxen, kmem is easier to use than mem, since you need not look up all the page tables. As long as the object of your search is in system space, you are OK. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu