home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8145 < prev    next >
Encoding:
Text File  |  1992-08-13  |  3.3 KB  |  75 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!boulder!ophelia!drew
  3. From: drew@ophelia.cs.colorado.edu (Drew Eckhardt)
  4. Subject: Re: Memory mapped files?
  5. Message-ID: <1992Aug13.200835.23931@colorado.edu>
  6. Sender: news@colorado.edu (The Daily Planet)
  7. Nntp-Posting-Host: ophelia.cs.colorado.edu
  8. Organization: University of Colorado at Boulder
  9. References: <1992Aug12.215042.5114@murdoch.acc.Virginia.EDU> <1992Aug13.054653.29996@colorado.edu> <1992Aug13.143944.17119@crd.ge.com>
  10. Date: Thu, 13 Aug 1992 20:08:35 GMT
  11. Lines: 62
  12.  
  13. In article <1992Aug13.143944.17119@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
  14. >In article <1992Aug13.054653.29996@colorado.edu>, drew@kinglear.cs.colorado.edu (Drew Eckhardt) writes:
  15. >| In article <1992Aug12.215042.5114@murdoch.acc.Virginia.EDU> lfoard@Turing.ORG (Lawrence C. Foard) writes:
  16. >| >Is there any soft of project underway to implement memory mapped files
  17. >| >in Linux? It seems that the shared library code is pretty close except
  18. >| >that it doesn't support writting pages back to the library file.
  19. >| >
  20. >| >Has anyone looked into what would be involved?
  21. >| 
  22. >| Ideally, some one will implement something along the lines of a 
  23. >| vnode based vm system, where each virtual memory object has a mapping
  24. >| and certain characteristics associated with it.
  25. >
  26. >  How about for a start someone fix mmap() to work? As the notes say "it
  27. >works well enough for X," but it sure isn't a generally working
  28. >implementation.
  29.  
  30. mmap() was only put in so that we could run 'X'.  The code reveals 
  31. the follow restriction : 
  32.  
  33.         /*
  34.          * for character devices, only /dev/mem may be mapped. when the
  35.          * swapping code is modified to allow arbitrary sources of pages,
  36.          * then we can open it up to regular files.
  37.          */
  38.  
  39.         if (major != 1 || minor != 1)
  40.                 return (caddr_t)-ENODEV;
  41.  
  42. So, you can mmap() /dev/mem, and map the frame buffer into your process's 
  43. space, but nothing else.
  44.  
  45. >
  46. >| That mapping could be to a file, to a device, etc.  Ideally, a file mapping
  47. >| would be a mapping to blocks as specified by the file's bmap, with those
  48. >| blocks shared with buffercache.  Shared libararies / mmap / sysV 
  49. >| shared memory semmantics could be implemented on top of this 
  50. >| internal structure, quite easily.
  51. >
  52. >  There is a question of what mechanism mmap uses now (I don't have
  53. >source code at work). 
  54.  
  55. Basically, it scrambles the page tables, and points an area in 
  56. your process's address space someplace else in physical memory.
  57.  
  58. >| Not 4G per process.  You still want room for kernel space in the 
  59. >| same page table, so you can keep most of the same code in place
  60. >| for kernel<>user space transfers, with kernel and user space in 
  61. >| different x86 segments. Linus has something going with
  62. >| > 3G per process, with the remainder allocated to the kernel - 
  63. >
  64. >  I guess HURD will have 1GB for the user, 1 for the kernel, and 2 for
  65. >the new release of emacs ;-) 
  66.  
  67. And the delays we're seeing are probably the HURD folks waiting for 
  68. 64 bit machine donations, because they've discovered that EMACS 19
  69. won't run in a puny 32 bit address space....
  70.  
  71. -- 
  72. Microsoft is responsible for propogating the evils it calls DOS and Windows, 
  73. IBM for AIX (appropriately called Aches by those having to administer it), but neither is as bad as AT&T.  Boycott AT&T, and let them know how you feel. 
  74.  
  75.