home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8507 < prev    next >
Encoding:
Text File  |  1992-08-17  |  4.3 KB  |  97 lines

  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!usc!elroy.jpl.nasa.gov!ames!agate!boulder!kinglear!drew
  3. From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
  4. Subject: Re: shared libs - can everyone be happy with this?
  5. Message-ID: <1992Aug18.031517.8187@colorado.edu>
  6. Sender: news@colorado.edu (The Daily Planet)
  7. Nntp-Posting-Host: kinglear.cs.colorado.edu
  8. Organization: University of Colorado at Boulder
  9. References: <1992Aug17.152210.23427@riacs.edu> <qddysb=@rpi.edu> <yddysh=@rpi.edu>
  10. Date: Tue, 18 Aug 1992 03:15:17 GMT
  11. Lines: 84
  12.  
  13. In article <yddysh=@rpi.edu> maniattb@cs.rpi.edu (Bill Maniatty) writes:
  14. >Newsgroups: comp.os.linux
  15. >Path: rpi!maniattb
  16. >From: maniattb@cs.rpi.edu (Bill Maniatty)
  17. >Subject: Re: shared libs - can everyone be happy with this?
  18. >Message-ID: <qddysb=@rpi.edu>
  19. >Nntp-Posting-Host: fornax.cs.rpi.edu
  20. >References: <NOP.92Aug16220027@theory.Mankato.MSUS.EDU> <1992Aug17.065450.28834@colorado.edu> <d-dyhz_@rpi.edu> <1992Aug17.152210.23427@riacs.edu>
  21. >Date: Mon, 17 Aug 1992 18:02:50 GMT
  22. >Lines: 49
  23. >
  24. >In article <1992Aug17.152210.23427@riacs.edu>, laredo@cc.gatech.edu (Nathan I. Laredo) writes:
  25. >|> In article <d-dyhz_@rpi.edu> maniattb@cs.rpi.edu (Bill Maniatty) writes:
  26. >|> >In article <1992Aug17.065450.28834@colorado.edu>, drew@ophelia.cs.colorado.edu (Drew Eckhardt) writes:
  27. >|> >|> In article <NOP.92Aug16220027@theory.Mankato.MSUS.EDU> nop@theory.Mankato.MSUS.EDU (Jay A. Carlson) writes:
  28. >|> >|> >In article <1992Aug15.042420.18914@serval.net.wsu.edu> hlu@phys1.physics.wsu.edu (Hongjiu Lu) writes:
  29. >|> >    [Stuff Deleted] 
  30. >|> >|> Also, if we ever unbreak Linux, writing to code space should trigger
  31. >|> >|> a segmentation fault - it's like it is now because the estdio library 
  32. >|> >|> was broken, and wrote to the code. 
  33. >|> >    Does linux permit self modifying code (by design or bug)?
  34. >|> >    This seems like a pretty bad ``feature''.
  35. >|> 
  36. >|> Hopefully we won't start another nasty chain here.. but someone correct
  37. >|> me if I'm wrong, but I've always been from the school that said that
  38. >|> all static variables went into the code space, otherwise how would
  39. >|> they be loaded in.
  40. >    [Stuff Deleted]
  41. >
  42. >I don't have a machine to run Linux on (yet :-) so I have to ask a stupid
  43. >question here.  My original post may have an incorrect assumption about
  44. >how memory management is performed.
  45. >
  46. >    I thought that traditional C compilers/linkers used the following segment
  47. >structure for memory management (for more details see Comer's Designing
  48. >Systems - the Xinu Approach)
  49. >
  50. >    text - instruction space
  51. >    data - initialized data space
  52. >    bss - uninitialized data space
  53. >    stack - stack segment
  54. >    (typically the heap and stack are at opposing ends of the same segment,
  55. >        and grow towards each other)
  56. >
  57. >I think data and bss could be combined into a single segment on 80x86.
  58.  
  59. True on both counts.
  60.  
  61. >How does linux do memory management at compile/run time?
  62.  
  63. Linux acts just like any other traditional unix : 
  64.  
  65. Each process is given a flat address space, starting 
  66. at 0, and currently ending at 64M.  This means that the program
  67. doesn't need relocation at load time, and therefore 
  68. multiple copies of the same program (or even
  69. different programs in the case of shared libraries) can share
  70. clean text and data pages.  
  71.  
  72. Code starts at 0, generally data (OMAGIC) at the next page boundary after 
  73. code ends so that code could be protected, although NMAGIC does not 
  74. pad to page boundaries.  Initialized 
  75. data follows code, followed by  BSS which is zero filled.  BSS and STACK
  76. grow towards each other, with stack starting at the 60M mark,
  77. and growing down.
  78.  
  79. Linux uses the top 4M of process address space for shared libraries.
  80.  
  81. Each process does not see the other processes address spaces.
  82.  
  83. >Also what flavors of memory protection does linux support?
  84.  
  85. Like I said, each process doesn't see the other's address space
  86. (different Intel segments, with descriptors in the LDT, 
  87. each process getting 64M in the page tables), so they 
  88. can't do anything.  The segments all have a 64M limit.
  89.  
  90. With shared pages, COW is implemented.  Also, text / data / etc
  91. aren't loaded or initialized until the system gets a page fault
  92. for a not present page.
  93. -- 
  94. Microsoft is responsible for propogating the evils it calls DOS and Windows, 
  95. 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. 
  96.  
  97.