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