Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.hawaii.edu!ames!olivea!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)
Message-ID: <veit.722878428@du9ds3>
Date: 27 Nov 92 15:33:48 GMT
References: <lohse.722861707@tech7> <JKH.92Nov27145531@whisker.lotus.ie>
Reply-To: veit@du9ds3.uni-duisburg.de
Organization: Uni-Duisburg FB9 Datenverarbeitung
Lines: 98
NNTP-Posting-Host: du9ds3.fb9dv.uni-duisburg.de
In <JKH.92Nov27145531@whisker.lotus.ie> jkh@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: veit@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"