home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8468 < prev    next >
Encoding:
Text File  |  1992-08-17  |  3.0 KB  |  73 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!usc!rpi!maniattb
  3. From: maniattb@cs.rpi.edu (Bill Maniatty)
  4. Subject: Re: shared libs - can everyone be happy with this?
  5. Message-ID: <yddysh=@rpi.edu>
  6. Sender: (null)@(null) ((null))
  7. Nntp-Posting-Host: fornax.cs.rpi.edu
  8. References: <NOP.92Aug16220027@theory.Mankato.MSUS.EDU> <1992Aug17.065450.28834@colorado.edu> <d-dyhz_@rpi.edu> <1992Aug17.152210.23427@riacs.edu> <qddysb=@rpi.edu>
  9. Date: Mon, 17 Aug 1992 18:09:37 GMT
  10. Lines: 61
  11.  
  12. Newsgroups: comp.os.linux
  13. Path: rpi!maniattb
  14. From: maniattb@cs.rpi.edu (Bill Maniatty)
  15. Subject: Re: shared libs - can everyone be happy with this?
  16. Message-ID: <qddysb=@rpi.edu>
  17. Nntp-Posting-Host: fornax.cs.rpi.edu
  18. References: <NOP.92Aug16220027@theory.Mankato.MSUS.EDU> <1992Aug17.065450.28834@colorado.edu> <d-dyhz_@rpi.edu> <1992Aug17.152210.23427@riacs.edu>
  19. Date: Mon, 17 Aug 1992 18:02:50 GMT
  20. Lines: 49
  21.  
  22. In article <1992Aug17.152210.23427@riacs.edu>, laredo@cc.gatech.edu (Nathan I. Laredo) writes:
  23. |> In article <d-dyhz_@rpi.edu> maniattb@cs.rpi.edu (Bill Maniatty) writes:
  24. |> >In article <1992Aug17.065450.28834@colorado.edu>, drew@ophelia.cs.colorado.edu (Drew Eckhardt) writes:
  25. |> >|> In article <NOP.92Aug16220027@theory.Mankato.MSUS.EDU> nop@theory.Mankato.MSUS.EDU (Jay A. Carlson) writes:
  26. |> >|> >In article <1992Aug15.042420.18914@serval.net.wsu.edu> hlu@phys1.physics.wsu.edu (Hongjiu Lu) writes:
  27. |> >    [Stuff Deleted] 
  28. |> >|> Also, if we ever unbreak Linux, writing to code space should trigger
  29. |> >|> a segmentation fault - it's like it is now because the estdio library 
  30. |> >|> was broken, and wrote to the code. 
  31. |> >    Does linux permit self modifying code (by design or bug)?
  32. |> >    This seems like a pretty bad ``feature''.
  33. |> 
  34. |> Hopefully we won't start another nasty chain here.. but someone correct
  35. |> me if I'm wrong, but I've always been from the school that said that
  36. |> all static variables went into the code space, otherwise how would
  37. |> they be loaded in.
  38.     [Stuff Deleted]
  39.  
  40. I don't have a machine to run Linux on (yet :-) so I have to ask a stupid
  41. question here.  My original post may have an incorrect assumption about
  42. how memory management is performed.
  43.  
  44.     I thought that traditional C compilers/linkers used the following segment
  45. structure for memory management (for more details see Comer's Designing
  46. Systems - the Xinu Approach)
  47.  
  48.     text - instruction space
  49.     data - initialized data space
  50.     bss - uninitialized data space
  51.     stack - stack segment
  52.     (typically the heap and stack are at opposing ends of the same segment,
  53.         and grow towards each other)
  54.  
  55. I think data and bss could be combined into a single segment on 80x86.
  56.  
  57. How does linux do memory management at compile/run time?
  58. Also what flavors of memory protection does linux support?
  59.  
  60. Bill
  61.  
  62. |> Nathan I. Laredo (this spot: $9) Internet: gt7080a@prism.gatech.edu 
  63. |> uucp:  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt7080a
  64. |> "Having had the correct view is nothing meritorious: statistically,
  65. |>  it is almost inevitable..."  -- Mr. Palomar,  On biting the tongue
  66.  
  67. -- 
  68. |
  69. |    maniattb@cs.rpi.edu - in real life Bill Maniatty
  70. |
  71.  
  72.  
  73.