Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: 386BSD SHARED LIBRARIES
Message-ID: <1992Sep12.180450.25086@fcom.cc.utah.edu>
Keywords: shared libraries X X11
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <veit.716107923@du9ds3> <7dnL02y821gh01@JUTS.ccc.amdahl.com> <veit.716291291@du9ds3>
Date: Sat, 12 Sep 92 18:04:50 GMT
Lines: 75
In article <veit.716291291@du9ds3> veit@du9ds3.uni-duisburg.de writes:
>My actual preference is the following system:
>Link an application with a special "stub library" that has undefined references
>to special "shared" code and data segments outside the standard _TEXT, _DATA
>and _BSS. There is a configurable shared library server that is loaded into
>memory at boot time (demand paging, of course) which has a symbol table in
>memory which contains the public references (Jump insn's) to the real
>libraries. The library server containing the library code is built for the
>shared data/text area. The program loader (kern_execve) resolves the lib
>references to the shared area, and makes the program's shared data segment
>copy-on-write so that it does not influence the memory of the library server.
>This dynamic linking does rely on the existance of a symbol table at some
>known location, but not on the number, the size, and the location of the
>shared modules.
I don't think you want to do user-land serving of the page requests; you
can probably do it just as easily by providing an object page mechanism
using the stubs and a well defined symbol resoloution mechanism to get
PIC offsets. The one problem I see here is large library routines crossing
page boundries and maintaining a per process page index. I think this can
be done by enforcing interdependency rules on the code and aligning it on
page boundries on load.
Obviously, this could be made faster if routines started on block
boundries so they could be paged directly off the disk when needed. I
see two possible mechanisms:
1) The code is paged off of disk as a result of a demand-read request
from within the kernel. This will have the effect of placing the
desired code in the buffer list hung off the locked vnode, which
is the shared library reference. It's probably questionable whether
copy-on-write can be implemented in this setup, and with multiple
processes it's likely that there will be contention problems. This
can be partially alleviated by copy-on-reference, but it's unlikely
that this would result in sharing of text segments without adding
another stage of support for hit-the-shared-image, hit-the-cache,
hit-the-disk.
2) Obtain multiple locked vnodes for a single process (one for the
executable file and one for each linked shared library), keeping
a common area and mapping the pages from the common area into each
process using the library. This would have to be done at load time,
so kern_exec would require modification, and the exit code would
have to decrement the lock reference. Other than the initial mapping
of pages containing PIC code and relocation of the process data as
a result of a change in offset, this could probably be handled by the
existing text sharing mechanism. The only drawback here is managing
the distinction between code pages and data pages so that one can
do copy-on-write rather than copying the data into each process
space initially... and it probably wouldn't be done on first
revision (ie: shared libraries are shared text only).
>
>Unfortunately, I'm currently not so deep inside the vm code of 386bsd, to
>decide whether this can be done in reasonable time, but I am willing
>to discuss about this and offer my help with implementation.
I don't know what you mean by a reasonable time... are we on a schedule 8-)?
I don't think it would take an unreasonable amount of time, and the vast
majority of the problems are still in the PIC generation, new assembler,
and linking against shared library stubs (which ar or ld would have to be
hacked to produced). Compared to the user-space work required, I still
think the kernel changes are trivial.
Terry Lambert
terry_lambert@gateway.novell.com
terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------