Newsgroups: comp.unix.bsd
Path: sparky!uunet!mcsun!Germany.EU.net!rzsun2.informatik.uni-hamburg.de!tech7!lohse
From: lo...@tech7.informatik.uni-hamburg.de (Joerg Lohse)
Subject: Shared Libraries for 386BSD (long, w/source)
Message-ID: <lohse.722861707@tech7>
Sender: n...@informatik.uni-hamburg.de (Mr. News)
Organization: University of Hamburg, FRG
Date: 27 Nov 92 10:55:07 GMT
Lines: 1378
This is an experimental implementation of shared libraries for 386BSD. This
implementation has the following properties:
- No kernel extension is necessary. Just the shared libraries need to be
installed in order to run programs using them.
- The shared libraries follow the approach used in System V: Shared libraries
are linked to fixed addresses and mapped in the address space at this
fixed address.
There are no symbols resolved at load-time as in AIX 3.x and SunOS.
- This package includes makefiles and programs that create shared version of
the C and X11 libraries and an extended version of the startup file crt0.o
- It also includes patches for the cc and g++ commands in order to link to
the shared version of the libc unless started with "-static". The shared
version of the libX11 must be explicitly specified as "-lX11_s".
I'm leaving for a job in another town. I haven't had time to implement exten-
sions that it would be nice to have. However, it's working as is.
I can't promise that email will reach me or that I can follow this news-group
within the next time, sorry.
Enjoy,
Joerg
-------------------------------------------------------------------------------
Dr. Joerg Lohse lo...@tech7.informatik.uni-hamburg.de
Fachbereich Informatik
Universitaet Hamburg I'm joining Siemens Corporate Research
Troplowitzstr. 7 in Munich on December 1st. Don't know
D-2000 Hamburg 54 the new internet address yet, sorry.
Germany
-------------------- cut here ------------------ cut here ---------------------
Source
Newsgroups: comp.unix.bsd
Path: sparky!uunet!mcsun!ieunet!dec4ie!jkh
From: j...@whisker.lotus.ie (Jordan K. Hubbard)
Subject: Re: Shared Libraries for 386BSD (long, w/source)
In-Reply-To: lohse@tech7.informatik.uni-hamburg.de's message of 27 Nov 92 10: 55:07 GMT
Message-ID: <JKH.92Nov27145418@whisker.lotus.ie>
Sender: use...@ieunet.ie (USENET News System)
Nntp-Posting-Host: whisker.lotus.ie
Organization: Lotus Development Ireland
References: <lohse.722861707@tech7>
Date: Fri, 27 Nov 1992 14:54:18 GMT
Lines: 7
Has anyone gotten any of this to work? I've heard that Jolitz et al were
working on their own implementation; does this mean that if I start using
this, I'll be looking at doing a major change of gears once 0.2 is released?
Thanks. If you care to reply via mail, I will summarize (if necessary).
Jordan
Path: sparky!uunet!mcsun!Germany.EU.net!unidui!du9ds3!veit
From: veit@du9ds3 (Holger Veit)
Newsgroups: comp.unix.bsd
Subject: Re: Shared Libraries for 386BSD (long, w/source)
Date: 27 Nov 92 15:33:48 GMT
Organization: Uni-Duisburg FB9 Datenverarbeitung
Lines: 98
Message-ID: <veit.722878428@du9ds3>
References: <lohse.722861707@tech7> <JKH.92Nov27145531@whisker.lotus.ie>
Reply-To: v...@du9ds3.uni-duisburg.de
NNTP-Posting-Host: du9ds3.fb9dv.uni-duisburg.de
In <JKH.92Nov27145...@whisker.lotus.ie> j...@whisker.lotus.ie (Jordan K. Hubbard) writes:
>Has anyone gotten any of this to work? I've heard that Jolitz et al were
>working on their own implementation; does this mean that if I start using
>this, I'll be looking at doing a major change of gears once 0.2 is released?
>Thanks. If you care to reply via mail, I will summarize (if necessary).
> Jordan
There are lots of rumors about 0.2, in particular on shared libraries.
I think I do not tell a secret if I say that there is an (small)
interest group (which Bill has an eye on, to avoid dirty hacks) which
works on shared libraries. The expected approach will be much like the SUN/OS
(or SVR4) versions of shared libraries. The code in the posting refered to
above is like the 1st approach of LINUX. Even the LINUX hackers have changed
this convention.
If you look into the code (or even only into the comments), you will read
that the shared libraries are at fixed locations and have fixed entry points.
This means that once you modify your source of e.g. libc (which is likely
because there are still bugs in it; there is always one more bug :-)),
all applications that refer to this shared library have to be at least
relinked :-(((( or the old shared libraries must remain in place.
You may use this code, it might work, but you should expect a number of
changes in 0.2 (I don't comment on this), which might cause a large number
of things work in a different way, or no longer at all. This applies in
particular to some (source) postings in the last few days or weeks, which are
mainly results of "the unknown, lonely, uninformed hacker" and are often
in no way acknowledged by THE WIZARD @ soda.berkeley.edu.
-----------------------------
I take this chance to ask all the "unknown hackers" (who might do good work,
nevertheless): If you have ported or written something, or want to write or
port something, PLEASE check first whether it has not already been done yet.
The workgroups forming at ref.tfs.com are a good reference of what is
going on. Ask one of the known bsd wizards *), whether your "super-duper
program/driver/whatsoever" is really in the line of 386bsd. What we do not
need is duplicate work and work which is incompatible to existing things
and will invalidate existing software. This should not cripple your creativity,
but coordination is necessary. I am not against competition, but not on
the shoulders of the people who mainly want to use 386bsd.
It might or might not be useful to adapt software to an existing interface,
e.g. some SysV compatible ioctls or a.out file formats, ... , just because
it is looking fine or other OS versions already use them. 386bsd is in the
tradition of Berkeley's BSD, it is a research system. It is not (mainly)
the social aspect to invent a cheap, full-featured UNIX operating system
for everyone for some 10 $ where commercial UNIX versions are in the
range of some 1000 $. The case BSDI/USL demonstrates what might happen
if someone with this attitude tries to break into commercial domains. The
larger vendors won't touch us for doing research (as we have seen, they profit
from this), but if they come to the opinion that they lose some market
segment to a 386bsd which has become a clone of their OS, they will undoubtedly
end our nice 386bsd play.
Invent a new, 100x faster filesystem, a better multitasking mechanism,
memory management, even an improved window system, etc. but don't try to
reverse engineer existing software and interfaces. 386bsd does not
try to become the next "OSF/2-Mach/HURD*DOS.V4.4+Linux" and integrate the
whole world; we already have such a monster named SVR4 which unsuccessfully
tries this.
Please also think about the fact that you as a skilled author know your
product best and are responsible for your child. You should be willing to
do (at least for a limited time!) support for this work. See the people
who might not understand your design and need help, or have suggestions
about improvements or bug reports. If you cannot afford this, please do
not release this code to the world. It will confuse more than being helpful.
The above shared lib code might be taken as an example.
(This is mainly my own opinion and not acknowlegded by Bill or Lynne,
but I think they would agree in the main points. This posting will be
forwarded to them, and if they totally disagree, there will be surely a
response, right, Lynne?).
----------------------
*) I do not consider me to belong to the wizards (I haven't disassembled
enough kernels yet ;-)), but if you really do not know anyone else, I
would be willing to forward some request to people who have better
knowledge of the business). BTW: Chris, Nate, Terry, David, Paul, Rich, and
other valuable persons, would you attend such a second level coordination
pool?
And finally, please users, for heaven's sake, do not flood Bill's mailbox with
trivial questions ("0.2, when???", or "where can I get ...").
Comp.unix.bsd now, and the proposed comp.os.386bsd.* hierarchy, is the
right forum for this. Vote for the forthcoming of 386bsd.
I think this had to be said.
Holger
--
| | / Dr. Holger Veit | INTERNET: v...@du9ds3.fb9dv.uni-duisburg.de
|__| / University of Duisburg | "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| | / Dept. of Electr. Eng. | Sorry, the above really good fortune has
| |/ Inst. f. Dataprocessing | been CENSORED because of obscenity"
Newsgroups: comp.unix.bsd
Path: sparky!uunet!mcsun!ieunet!dec4ie!jkh
From: j...@whisker.lotus.ie (Jordan K. Hubbard)
Subject: Re: Shared Libraries for 386BSD (long, w/source)
In-Reply-To: veit@du9ds3's message of 27 Nov 92 15: 33:48 GMT
Message-ID: <JKH.92Nov27180432@whisker.lotus.ie>
Sender: use...@ieunet.ie (USENET News System)
Nntp-Posting-Host: whisker.lotus.ie
Organization: Lotus Development Ireland
References: <lohse.722861707@tech7> <JKH.92Nov27145531@whisker.lotus.ie>
<veit.722878428@du9ds3>
Date: Fri, 27 Nov 1992 18:04:32 GMT
Lines: 37
You make some good points.
On the subject of cooperative efforts, I assume you also saw (and to
some extent were responding to) the pccons driver recently posted? I
mailed the author and thanked him for his work, but explained that I
was already committed to your driver and didn't want to switch drivers
a 3rd time. I also wondered at how he had managed to develop such a
driver in isolation, without seeing your previous work. Perhaps a
more informal mailing list arm of the ref.tfs.com working groups needs
to be set up to deal with people more on the "fringes" of the
development community.
We need to remember that not everyone has USENET or INTERNET
connectivity and I think in some cases the message just isn't getting
through.
As to the pccons driver, it would be nice to see some of the features
of his driver incorporated into yours - specifically the virtual terminal
handling.
For the record, I don't think that going for a 'full-featured' UNIX
operating system as one of 386BSD's goals is necessarily that bad of
an idea, either. Don't forget that for many people, UNIX is merely
the means to an end (I.E. a platform on which one can develop actual
research APPLICATIONS). Just because some of us enjoy hacking on the
kernel doesn't mean that 386BSD has to forever remain a playground for
our interests only. I suspect that, at some point the the distant
future, you'll see a 'stable' 386BSD thread and a 'research' one, much
like what's currently being done for gcc. I, for one, would heartily
endorse such a thing.
There does come a time when one wants to stop playing with the kernel
and get down to writing user-level code on a platform that doesn't
necessarily crash every day.
Jordan
|