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.