*BSD News Article 20427


Return to BSD News archive

Xref: sserve comp.os.386bsd.questions:4842 comp.os.386bsd.misc:873 comp.os.386bsd.development:1185
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc,comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!sdd.hp.com!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [ANSWER to question] How to format a floppy for 386bsd
Message-ID: <1993Sep4.223623.1007@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University, Ogden, UT
References: <MYCROFT.93Sep2025505@trinity.gnu.ai.mit.edu> <1993Sep2.174803.29376@fcom.cc.utah.edu> <CCsDJu.A1q@austin.ibm.com>
Date: Sat, 4 Sep 93 22:36:23 GMT
Lines: 60

In article <CCsDJu.A1q@austin.ibm.com> boyd@austin.ibm.com writes:
>
>In article <1993Sep2.174803.29376@fcom.cc.utah.edu>, terry@cs.weber.edu (A Wizard of Earth C) writes:
>> For many reasons (well known to others, Charles included), I can't
>> make the code changes myself and then make them available

>[ ... ] will [ ... code ... ] be available soon?!  Define "real"
>[ ... shared libraries ... ], please.  Oh, and which set of politics?
>There seem to be so many and I am having trouble determining which is
>which.  Sorry, I haven't been paying enough attention :-)

I work for a company that bought a company that sells UNIX, and I have a
non-compete agreement.  All code release must be approved by legal... it's
currently in code-limbo.

Real shared libraries are those using PIC compilation so that they don't
depend on being at a particuar place in an image (subject to page alignment
restrictions).  The Joerg/modified Joerg shared libraries are a working
shared library implementation, but:

o	They are difficult to update successfully.
o	Because each library must be at a fixed address, there
	is contention resoloution required as to who gets what
	starting address.
o	There is contention about how big an address range is allocated
	to a library -- too small, and you limit expandability, too
	large, and you limit process size and the number of libs
	available.
o	Each new library version (practically) requires its own new
	slot.
o	The same code can not be used to produce a statically linked
	image -- you have to have two library versions

Sun has a good implementation; in fact, Sun's code was made available to
BSD 4.4 and to the *BSD projects; however, the path which it took to get
to the *BSD projects was legally suspect.  This was unfortunate, because
I had it working before my non-compete kicked in.  I started over from
scratch, but by then my company had started its acquisition and my hands
were tied.  I now have a working non-suspect version that I can't release,
along with *many* other things I'd like to.

I have heards of two other projects on the same lines, so hopefully there
will be something without my code being needed.  Maybe the dynamic link
code in C++ out of UofU (see the Usenix paper) can be adapted.

All that said, shared libraries aren't that big a deal unless you are very
limited on disk (text is already shared between similar processes, so a
bunch of xterms are no more expensive than they would be with shared libs),
so I don't see them as a real big issue -- *BSD is hackerware, and it's
traditional that sources are needed, and so disks will need to be larger.
The savings aren't as significant as you might think (for memory, if you
are running a lot of homogenous apps) or for disk (if you have to have 80
to 100 M anyway).


					Terry Lambert
					terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.