Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:4847 comp.os.386bsd.misc:877 comp.os.386bsd.development:1187 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!haven.umd.edu!darwin.sura.net!wupost!csus.edu!netcom.com!hasty From: hasty@netcom.com (Amancio Hasty Jr) Subject: Re: [ANSWER to question] How to format a floppy for 386bsd Message-ID: <hastyCCv4Gt.7qo@netcom.com> Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: <1993Sep2.174803.29376@fcom.cc.utah.edu> <CCsDJu.A1q@austin.ibm.com> <1993Sep4.223623.1007@fcom.cc.utah.edu> Date: Sun, 5 Sep 1993 04:00:28 GMT Lines: 99 In article <1993Sep4.223623.1007@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >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. For quite sometime now, PIC patches, I guess for gcc, have been available at sunlamp In VMS, we had a simple scheme, vector jump addresses, a given vector could be made large enough to accomodate new entries for new routines. So it is conceivable that all shared libraries to either use a single vector or use their own. >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). I disagreed with the above many including myself would love to just download binaries. X applications are notorious for the diskspace that they consume. If *BSD is to grow out of the hackerware mentally then I think that shared library is a must. A great attraction to 386bsd could be a group of ftp sites with various popular packages pre-compiled for the end-user. An example and very successfull project has been XFree86 and the XS3 server; hardly anyone ever compiles XS3, they just use it or complain to me about problems :-) Interviews, flexfax, GoPath (a c++ library similar but superior to Interviews) are examples of packages that are unfeasible for the end community to just download the sources and compile them. In fact, in certain cases due to gcc and lack of swap space some of theses apps may not compile on some systems and if they do it will take a long time to compile them. Perhaps, what I am attempting to adddress is the need of a shrink wrap product concept for 386bsd. I think that this is very strong OS oriented group and that the application aspects are perhaps lacking behind. Please, observe how many postings have been made to comp.os.386bsd.apps. It has been said that if the OS is strong and good that the rest will follow well so far not many pre-compiled apps have followed. Good Nite, Amancio -- This message brought to you by the letters X and S and the number 3 Amancio Hasty | Home: (415) 495-3046 | ftp-site depository of all my work: e-mail hasty@netcom.com | sunvis.rtpnc.epa.gov:/pub/386bsd/incoming