Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!uunet!spool.mu.edu!darwin.sura.net!mojo.eng.umd.edu!pandora.pix.com!stripes
From: stripes@pix.com (Josh Osborne)
Subject: Re: Shared Libs for X11?, was Re: 386bsd -- The New Newsgroup
Message-ID: <BuryyA.C4u@pix.com>
Sender: news@pix.com (The News Subsystem)
Nntp-Posting-Host: pandora.pix.com
Organization: Pix Technologies -- The company with no adult supervision
References: <2aFn02vQ22Jx01@JUTS.ccc.amdahl.com> <Buo74w.Jp2@pix.com> <77aD02m3229d01@JUTS.ccc.amdahl.com>
Date: Fri, 18 Sep 1992 13:03:45 GMT
Lines: 44
In article <77aD02m3229d01@JUTS.ccc.amdahl.com> gab10@cd.amdahl.com (Gary A Browning) writes:
>In article <Buo74w.Jp2@pix.com>, stripes@pix.com (Josh Osborne) writes:
>> Runtime linked code will not allways be the same for each copy of the
>> same executable. Not if we support a library path like Sun does (which
>> is a good idea), or if a new lib is installed after starting one copy of
>> xterm but before another is started.
>
>So am I correct in saying that the text is modified on initial load and,
>as long as the revisions of the libraries are the same for each new
>instantiation, the text is still sharable between process?
Is it sharable? Yes. Is it easy to share? No. The easy thing to do
is let the runtime linker map the pages it needs to patch up rwx, patch
them up, then put them back to r-x. That _should_ make the kernel allocate
backing store for each page for each proc. Somewhat harder would be for
the runtime linker to map the pages to /someplace/exec-devno/exec-vnum/lib-
devno/lib-vnum (or some other name unique for each executable-lib pair)
and patch it up, that would share the pages without the kernel needing to
be able to do anything more complex then a proper mmap (not that mmap is
easy...). Of corse you then have problems when 1 page references >1
diffrent shared lib, I guess you need a more complex naming scheme.
>Note that this also implies that the binary image on disk is insuffient
>to use for recovering pages that have been removed from the processes'
>working set. These processes will need to have space allocated in the swap
>space on disk and treated similarly to data pages (at least when initially
>removed from memory, then it never changes again so it will not need to
>be written out again).
Yep, unless you want to make a "branch/jump/whatever" to non-existant address
invoke the runtime linker to fix-up the reference, but if you did that you
should add 56-bit msec clocks, 36-bit addresses, and the rest of Multics
too :-) (Ok, Multics used a valid address, but had a bit in the opcode
meaning "OS, fix me up!", same basic idea 'tho).
Oh, it could change >1 time depending on how late you allow binding, and
if you let a process re-bind to a diffrent shared lib (I don't think it is
worth it).
--
stripes@pix.com "Security for Unix is like
Josh_Osborne@Real_World,The Multitasking for MS-DOS"
"The dyslexic porgramer" - Kevin Lockwood
We all agree on the necessity of compromise. We just can't agree on
when it's necessary to compromise. - Larry Wall