home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / sysv386 / 14115 < prev    next >
Encoding:
Text File  |  1992-09-08  |  1.7 KB  |  41 lines
  1. Newsgroups: comp.unix.sysv386
  2. Path: sparky!uunet!wupost!gumby!destroyer!ais.org!lewis
  3. From: lewis@ais.org (David T. Lewis)
  4. Subject: Re: What is /dev/pmem?
  5. Message-ID: <Bu6745.C58@ais.org>
  6. Summary: physical memory
  7. Sender: Dave Lewis
  8. Organization: UMCC
  9. References: <1992Aug31.152303.20833@cbnewsj.cb.att.com> <1992Sep2.193151.16817@cti-software.nl>
  10. Date: Sun, 6 Sep 1992 18:52:51 GMT
  11. Lines: 28
  12.  
  13. In article <1992Sep2.193151.16817@cti-software.nl> pim@cti-software.nl 
  14. (Pim Zandbergen) writes:
  15. >dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
  16. >
  17. >
  18. >>On my SVR4 box (Microport), in addition to the standard /dev/mem and
  19. >>/dev/kmem, there is a /dev/pmem.  All three have different minor mumbers 
  20. >>(same major number, so /dev/pmem is obviously related to the other two).
  21. >>The manual page for /dev/mem and /dev/kmem has no mention of /dev/pmem.
  22. >>Can anyone enlighten me on what this is?
  23. >
  24. >I've asked the same question a couple of months ago, because
  25. >there's also a /dev/pmem in Interactive's SVR3.2.
  26. >
  27. >I had zero response then, I wonder if there will be any now.
  28. >-- 
  29. >Pim Zandbergen                      domain : pim@cti-software.nl
  30. >CTI Software BV                     uucp   : uunet!mcsun!sun4nl!ctisbv!pim
  31. >Laan Copes van Cattenburch 70       phone  : +31 70 3542302
  32. >2585 GD The Hague, The Netherlands  fax    : +31 70 3512837
  33.  
  34. Please forgive me taking a wild guess at it, but "physical memory" comes
  35. to mind.  Possibly this is to provide access to hardware memory addresses,
  36. as distinct from addresses which get translated through the memory mapping
  37. hardware.  If you can read your video card memory from address 0xA0000 or
  38. 0xB0000 of /dev/pmem, the hypothesis would be supported.  Obviously,
  39. writing to this device would be a bit on the risky side.
  40.  
  41.