From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: shared libs - can everyone be happy with this?
Organization: University of Colorado at Boulder
Date: Tue, 18 Aug 1992 03:15:17 GMT

In article <yddysh=@rpi.edu> maniattb@cs.rpi.edu (Bill Maniatty) writes:
>Newsgroups: comp.os.linux
>Path: rpi!maniattb
>From: maniattb@cs.rpi.edu (Bill Maniatty)
>Subject: Re: shared libs - can everyone be happy with this?
>Message-ID: <qddysb=@rpi.edu>
>Nntp-Posting-Host: fornax.cs.rpi.edu
>References: <NOP.92Aug16220027@theory.Mankato.MSUS.EDU> <1992Aug17.065450.28834@colorado.edu> <d-dyhz_@rpi.edu> <1992Aug17.152210.23427@riacs.edu>
>Date: Mon, 17 Aug 1992 18:02:50 GMT
>Lines: 49
>
>In article <1992Aug17.152210.23427@riacs.edu>, laredo@cc.gatech.edu (Nathan I. Laredo) writes:
>|> In article <d-dyhz_@rpi.edu> maniattb@cs.rpi.edu (Bill Maniatty) writes:
>|> >In article <1992Aug17.065450.28834@colorado.edu>, drew@ophelia.cs.colorado.edu (Drew Eckhardt) writes:
>|> >|> In article <NOP.92Aug16220027@theory.Mankato.MSUS.EDU> nop@theory.Mankato.MSUS.EDU (Jay A. Carlson) writes:
>|> >|> >In article <1992Aug15.042420.18914@serval.net.wsu.edu> hlu@phys1.physics.wsu.edu (Hongjiu Lu) writes:
>|> >	[Stuff Deleted] 
>|> >|> Also, if we ever unbreak Linux, writing to code space should trigger
>|> >|> a segmentation fault - it's like it is now because the estdio library 
>|> >|> was broken, and wrote to the code. 
>|> >	Does linux permit self modifying code (by design or bug)?
>|> >	This seems like a pretty bad ``feature''.
>|> 
>|> Hopefully we won't start another nasty chain here.. but someone correct
>|> me if I'm wrong, but I've always been from the school that said that
>|> all static variables went into the code space, otherwise how would
>|> they be loaded in.
>	[Stuff Deleted]
>
>I don't have a machine to run Linux on (yet :-) so I have to ask a stupid
>question here.  My original post may have an incorrect assumption about
>how memory management is performed.
>
>	I thought that traditional C compilers/linkers used the following segment
>structure for memory management (for more details see Comer's Designing
>Systems - the Xinu Approach)
>
>	text - instruction space
>	data - initialized data space
>	bss - uninitialized data space
>	stack - stack segment
>	(typically the heap and stack are at opposing ends of the same segment,
>		and grow towards each other)
>
>I think data and bss could be combined into a single segment on 80x86.

True on both counts.

>How does linux do memory management at compile/run time?

Linux acts just like any other traditional unix : 

Each process is given a flat address space, starting 
at 0, and currently ending at 64M.  This means that the program
doesn't need relocation at load time, and therefore 
multiple copies of the same program (or even
different programs in the case of shared libraries) can share
clean text and data pages.  

Code starts at 0, generally data (OMAGIC) at the next page boundary after 
code ends so that code could be protected, although NMAGIC does not 
pad to page boundaries.  Initialized 
data follows code, followed by  BSS which is zero filled.  BSS and STACK
grow towards each other, with stack starting at the 60M mark,
and growing down.

Linux uses the top 4M of process address space for shared libraries.

Each process does not see the other processes address spaces.

>Also what flavors of memory protection does linux support?

Like I said, each process doesn't see the other's address space
(different Intel segments, with descriptors in the LDT, 
each process getting 64M in the page tables), so they 
can't do anything.  The segments all have a 64M limit.

With shared pages, COW is implemented.  Also, text / data / etc
aren't loaded or initialized until the system gets a page fault
for a not present page.
-- 
Microsoft is responsible for propogating the evils it calls DOS and Windows, 
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.