From: terry@cs.weber.edu (A Wizard of Earth C)
Newsgroups: comp.unix.bsd
Subject: 386BSD SHARED LIBRARIES
Keywords: shared libraries X X11
Date: 12 Sep 92 18:04:50 GMT
Organization: Weber State University  (Ogden, UT)

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
-------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd