Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!newsserver.jvnc.net!gmd.de!mururoa!veit
From: veit@mururoa.gmd.de (Holger Veit)
Subject: Re: Shared libraries and 386bsd.
Message-ID: <1993Mar25.075627.5005@gmd.de>
Sender: veit@mururoa (Holger Veit)
Nntp-Posting-Host: mururoa.gmd.de
Organization: GMD - German National Research Center for Computer Science
References: <MCKIM.93Mar23082603@dinah.lerc.nasa.gov> <1onp3o$l3v@umd5.umd.edu> <33426@castle.ed.ac.uk> <1oqfm3$i6q@umd5.umd.edu>
Date: Thu, 25 Mar 1993 07:56:27 GMT
Lines: 56
In article <1oqfm3$i6q@umd5.umd.edu>, mark@roissy.umd.edu (Mark Sienkiewicz)
writes:
[...]
|> >From: veit@mururoa.gmd.de (Holger Veit)
[...]
|> In this next section, I was talking about two different things:
|>
|> >It shouldn't be the task of an application to take care where to find
|> >its data and addresses. Once it is loaded into memory, it is the job of the kernel
|> >to guarantee that everything which is needed is (transparently) there.
|>
|> If you mean that the application shouldn't have to do it's own paging, I
|> agree. If you are saying the application should not have to understand
|> it's own data, then I disagree.
No, I wasn't aiming at paging by the application, nor did I mean that an
application shouldn't have to understand its own data. Partitioning for instance
the data section of a process in different segments introduces a substructure,
a process usually doesn't need to know (e.g. knowledge that some data was linked
in from different sources by examining the segment part of the pointer).
There is no benefit in it if applied in the standard way (such as protection).
If the process could determine to switch a part of the data to read-only,
for instance, this might be an interesting application of segments, but this
moves some kernel task into the user process. (See also below).
|>
|> There is another thought that is not quite clearly expressed in the above
|> discussion, so I will explictly state it here:
|>
|> I think that a shared library may be made responsible for handling issues
|> that result from it being a shared library.
|> I do NOT expect that a shared library can be made by simply converting
|> libfoo.a into libfoo.sl -- I expect there will need to be _some_ code
|> changes. _How_much_ code to change is an issue, but I expect there
|> will be some.
I don't like the idea to write code in a library to adapt it to a special
method of linking. This should be transparently done by the loader or archiver
or another process. If it requires to compile the objects with -PIC, this is
okay. But including code like "if I am shared, I do this, else do that"
is at least error-prone. Things like this have been already done, but if we have
a chance to avoid it (we have, because the last word on shared libs has not yet
been spoken), we should consider the best solution.
|> Mark S.
Holger
--
Dr. Holger Veit | INTERNET: Holger.Veit@gmd.de
| | / GMD-SET German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Computer Science | Fax: (+49) 2241 14 2342
| | / P.O. Box 13 16 | Three lines Signature space
| |/ Schloss Birlinghoven | available for rent. Nearly
DW-5205 St. Augustin, Germany | unused, good conditions