Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Jan 1997 22:26:17 -0500 (EST)
From:      Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
To:        softweyr@xmission.com, ponds!lemis.de!grog
Cc:        ponds!freebsd.org!questions
Subject:   Re: the UNIX hole
Message-ID:  <199701160326.WAA05493@lakes.water.net>

next in thread | raw e-mail | index | archive | help
> 
> Mike Branch writes:
> %   could anybody give an explanation about the UNIX "hole"?
> % Is the hole filled in current versions of UNIX?  Is it
> % still advisable to configure devices in contiguous memory
> % locations when building a kernel?
> 
> Greg Lemis replied:
> > (You can tell how far behind I am with my mail :-()
> > 
> > I didn't see a reply to this one, and since I've never heard of the
> > "UNIX hole", I thought I'd ask you what you mean.
> 
> I skipped over this when I first read it because it sounded like the
> original author was from outer space.  Now that I've seen it again, and
> my brain has had a few days to rebuild the associative links, I
> remember some bizarre problems running SVR3 apps on early i386 SVR4
> systems, something to do with a giant hole placed between the text and
> data segments when the program loaded.
> 
> If this is what you're talking about, Mike, it has never existed in BSD
> UNIX, and still doesn't.  ;^)  And no, you can configure devices pretty
> much wherever you want in memory, though on the PC architecture* most
> devices use only I/O addresses and not memory addresses.
> 
> 
> * Sorry, the phrase "PC architecture" just sent my brain spinning, I'm
> trying to recover.  The idea that someone actually *designed* this mess
> boggles...
> 

 Well - usually there is a "hole" - but it's done on purpose.

 Generically (and you can invert the up/down in the following, particularly
on PCs - and I'm leaving out *lots* of details) - a program loaded on
a UNIX machine can be thought of as a few sections and a stack and a
heap (I'm also greatly simplifying here; typically there are actually
more sections and there's no reason they need to be contiguous, etc...
but I'm trying to illustrate) - When a program is running in it's
virtual address space - it looks like:

    ++++++++++++++++
    |   program    |
    |    (.text)   |
    ++++++++++++++++
    |  initialized |
    |  data        |
    |   (.data)    |
    ++++++++++++++++
    | uninitialized|
    |  data (.bss) |
    ++++++++++++++++ <- end
    |  stack       |
    |    |         |
        \|/      

       (hole)

        /|\
    |    |         | <- sbrk
    |  heap        |
    ++++++++++++++++


 The "heap" grows toward the program stack. 

 So, there is a virtual "hole" in-between them... but, so what?

 Now, on PCs there is another "hole" between 640K and the first 1M.
Also, there is a "hole" in high memory used by the BIOS... but with
virtual memory these aren't "really" there; just physically there.

	- Dave R. -



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701160326.WAA05493>