Path: bga.com!news.sprintlink.net!redstone.interpath.net!ddsw1!panix!
MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!spool.mu.edu!
agate!darkstar.UCSC.EDU!news.hal.COM!halsoft.com!news.halsoft.com!connolly
From: conno...@ulua.hal.com (Dan Connolly)
Newsgroups: comp.os.linux.development
Subject: Shared Libs: working toward a permanent solution?
Date: 14 Sep 1994 15:39:40 GMT
Organization: HaL Software Systems, Inc.
Lines: 41
Distribution: world
Message-ID: <CONNOLLY.94Sep14103940@ulua.hal.com>
NNTP-Posting-Host: ulua.halsoft.com
Forgive me if this has been hashed over in this forum before... I've
been following c.o.l.d for about a month, and I haven't seen it (nor
is it in the FAQs, HOWTOs, or any other documentation that I can
find...)
The current architecture for shared libraries seems to work pretty
well, but it seems tedious to build shared libraries, and the fact
that you have to somehow magically choose a part of the address space
that noone else will ever use strikes me as somewhat fragile. The
technique of reducing loader symbols to integer indexes seems fragile
also.
[Quick question: shared libraries _are_ in fact shared between
processes in the sense that program if program A and program B are
both using shared library X, there is only one copy of X in physical
memory, right? There isn't any runtime "patching" that makes shared
libraries unique to a process, is there?]
So is there a project underway to replace the current shared library
tools with conventional name-based shared libraries? This seems like a
big compatibility nightmare, but it's worth it, I think. And the
sooner we do it, the better.
How are SVR4 shared libraries done? (perhaps I should do some reading
here...) It seems that the "commercial" x86 unix platforms are SVR4
based. What are the major gaps between LINUX as it is today and SVID
compliance? Hmmm... I should do some reading on ELF and the iBCS
project. Is there any hope that solaris binaries will run on LINUX?
Solaris/intel seems like it's shaping up to become a viable platform.
It might be nice to be able to ride that wave...
Pointers toward the relavent discussion forums, source distributions,
newsgroups, etc. are appreciated.
Dan
--
Daniel W. Connolly "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010
<conno...@hal.com> http://www.hal.com/%7Econnolly/index.html
Path: bga.com!news.sprintlink.net!sundog.tiac.net!wizard.pn.com!
Germany.EU.net!EU.net!uunet!sun.cais.com!news.cais.com!cais.cais.com!ericy
From: er...@cais.cais.com (Eric Youngdale)
Newsgroups: comp.os.linux.development
Subject: Re: Shared Libs: working toward a permanent solution?
Date: 16 Sep 1994 12:38:40 GMT
Organization: Capital Area Internet Service i...@cais.com
Lines: 56
Message-ID: <35c3kg$klg@news.cais.com>
References: <CONNOLLY.94Sep14103940@ulua.hal.com>
NNTP-Posting-Host: cais.com
In article <CONNOLLY.94Sep14103...@ulua.hal.com>,
Dan Connolly <conno...@ulua.hal.com> wrote:
>[Quick question: shared libraries _are_ in fact shared between
>processes in the sense that program if program A and program B are
>both using shared library X, there is only one copy of X in physical
>memory, right? There isn't any runtime "patching" that makes shared
>libraries unique to a process, is there?]
This is correct. The .text pages are all shared between different
processes. The .data pages are shared until the process modifies them, after
which time they are no longer shared.
>So is there a project underway to replace the current shared library
>tools with conventional name-based shared libraries? This seems like a
>big compatibility nightmare, but it's worth it, I think. And the
>sooner we do it, the better.
Tell me about it :-).
>How are SVR4 shared libraries done? (perhaps I should do some reading
>here...) It seems that the "commercial" x86 unix platforms are SVR4
>based. What are the major gaps between LINUX as it is today and SVID
>compliance? Hmmm... I should do some reading on ELF and the iBCS
>project. Is there any hope that solaris binaries will run on LINUX?
>Solaris/intel seems like it's shaping up to become a viable platform.
>It might be nice to be able to ride that wave...
All of the SVr4 platforms use ELF, and with ELF all of the binding
of symbols to addresses is done at runtime. There are hash tables and
other optimizations in place in order to ensure that this process is fast.
Solaris binaries should run under Linus using the iBCS2 code.
As far as the native format is concerned, there is an effort underway
to fix things so that it would be possible to use ELF as the native
format for linux. I do not want to rush this as there are lots of apps
which might depend upon a.out in some way, but for now we have a set
of compilers, binutils and libc that are ELF which people are testing.
Someone tried Emacs (and uncovered some problems, not all of which are
resolved yet), and someone else will be trying to generate the ELF versions
of the X shared libraries.
Some people have concerns about the performance of ELF shared
libraries because they must be PIC. So far I have not seen much
difference, but the tests that I have run are preliminary (i.e. I have not
tried very hard). Once we get the X libraries it will be easier to test
(i.e. the apps will spend more time in the shared libraries).
The main advatage of ELF from a library developer's standpoint is that
building an ELF shared library is about as easy as compiling and linking
it.
-Eric
--
"The woods are lovely, dark and deep. But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."
Newsgroups: comp.os.linux.development
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!pipex!uknet!info!iialan
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Shared Libs: working toward a permanent solution?
Message-ID: <Cw8B6I.I62@info.swan.ac.uk>
Sender: n...@info.swan.ac.uk
Nntp-Posting-Host: iifeak.swan.ac.uk
Organization: Institute For Industrial Information Technology
References: <CONNOLLY.94Sep14103940@ulua.hal.com> <35c3kg$klg@news.cais.com>
Date: Fri, 16 Sep 1994 15:32:41 GMT
Lines: 37
In article <35c3kg$...@news.cais.com> er...@cais.cais.com (Eric Youngdale) writes:
>libraries because they must be PIC. So far I have not seen much
>difference, but the tests that I have run are preliminary (i.e. I have not
>tried very hard). Once we get the X libraries it will be easier to test
>(i.e. the apps will spend more time in the shared libraries).
X is a poor test. Most X time is in the servers or paging unless you have
a very fast machine - Try stuff like the crypt() performance, non disk
bound stdio throughput tests (eg pipe based), qsort() and other big
library routines. Also remember to evaluate the calling sequence time
as that is very important too.
0-30% slower depending on the exact code involved. Certainly not acceptable.
If I wanted my machine to run 20% slower I'd buy SCO 8). In theory you can
cheat and keep relink information with the libraries (in a different file
as we don't want to violate the notional ELF standard). With suitably
picked addresses your libraries will just never happen to collide. If they
do then you suffer a slowdown caused by some pages being doubled. Doing
ELF libraries on a 386/486 is hard even if you modify the kernel to allow
you to borrow other segment registers to hide the worst of the situation.
Some CPU's like the 680x0 generally run faster using PC relative
addressing.. but the x86 hates it.
If people do decide to use ELF libraries please make the old format
libraries available and linkable with. A 20% slowdown is the different
between a 486DX50 and a 486DX33. Most programs spend >75% of their cpu time
in the libraries so they must be fast first and featuritis can come later.
Some libraries such as svgalib already have to do a few tricks to avoid the
slowdowns caused by the fixed libraries.
Alan
Who won't be using PC relative libraries
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`----------------------------'`----------------------------''
Path: bga.com!news.sprintlink.net!uunet!MathWorks.Com!news.kei.com!ddsw1!
not-for-mail
From: macgy...@MCS.COM (MacGyver)
Newsgroups: comp.os.linux.development
Subject: Re: Shared Libs: working toward a permanent solution?
Date: 16 Sep 1994 13:16:52 -0500
Organization: TOS Enterprises.
Lines: 32
Message-ID: <35cnek$j2i@Venus.mcs.com>
References: <CONNOLLY.94Sep14103940@ulua.hal.com> <35c3kg$klg@news.cais.com>
<Cw8B6I.I62@info.swan.ac.uk>
NNTP-Posting-Host: venus.mcs.com
X-Newsreader: TIN [version 1.2 PL2 (KSD)]
Alan Cox (iia...@iifeak.swan.ac.uk) wrote:
: In article <35c3kg$...@news.cais.com> er...@cais.cais.com (Eric Youngdale) writes:
: >libraries because they must be PIC. So far I have not seen much
: >difference, but the tests that I have run are preliminary (i.e. I have not
: >tried very hard). Once we get the X libraries it will be easier to test
: >(i.e. the apps will spend more time in the shared libraries).
: X is a poor test. Most X time is in the servers or paging unless you have
: a very fast machine - Try stuff like the crypt() performance, non disk
: bound stdio throughput tests (eg pipe based), qsort() and other big
: library routines. Also remember to evaluate the calling sequence time
: as that is very important too.
: 0-30% slower depending on the exact code involved. Certainly not acceptable.
: If I wanted my machine to run 20% slower I'd buy SCO 8). In theory you can
: cheat and keep relink information with the libraries (in a different file
: as we don't want to violate the notional ELF standard). With suitably
: picked addresses your libraries will just never happen to collide. If they
: do then you suffer a slowdown caused by some pages being doubled. Doing
: ELF libraries on a 386/486 is hard even if you modify the kernel to allow
: you to borrow other segment registers to hide the worst of the situation.
A question then...why do people USE ELF if it slows down the system that much?
I'm not sure I see what's wrong with the current a.out stuff personally,
although I don't know much about a.out or ELF (if ANYONE knows where I can read
up on this stuff, please point me to a book, an FTP side, a paper, anything! :)
but it sounds like people merely want it to run binaries of other platforms...
what's wrong with just using the sutff in Linux? I see very few apps that I
personally would ever want to run that I can't get for Linux (the only
exceptions being DOS and Windoze apps).
HJD.
Path: bga.com!news.sprintlink.net!sun.cais.com!news.cais.com!cais.cais.com!ericy
From: er...@cais.cais.com (Eric Youngdale)
Newsgroups: comp.os.linux.development
Subject: Re: Shared Libs: working toward a permanent solution?
Date: 17 Sep 1994 04:01:29 GMT
Organization: Capital Area Internet Service i...@cais.com
Lines: 30
Message-ID: <35dpmp$qih@news.cais.com>
References: <CONNOLLY.94Sep14103940@ulua.hal.com> <35c3kg$klg@news.cais.com>
<Cw8B6I.I62@info.swan.ac.uk>
NNTP-Posting-Host: cais.com
In article <Cw8B6I....@info.swan.ac.uk>,
Alan Cox <iia...@iifeak.swan.ac.uk> wrote:
>X is a poor test. Most X time is in the servers or paging unless you have
>a very fast machine - Try stuff like the crypt() performance, non disk
>bound stdio throughput tests (eg pipe based), qsort() and other big
>library routines. Also remember to evaluate the calling sequence time
>as that is very important too.
OK, qsort would be a reasonable test, I suppose. In the end, what
really matters is how actual applications behave. The tests that I have
run so far indicate a < 1% difference.
>Some CPU's like the 680x0 generally run faster using PC relative
>addressing.. but the x86 hates it.
People keep forgetting that to achieve the current shared
libraries that we had to add a "filter" which rewrites some of the
assembly code and adds extra indirections to any access to global
variables. Before we can use any register, we need to save the old one on
the stack, and then it needs to be restored when we are through. Also,
rewriting assembly in this way this is hard to optimize for performance,
so I would have a hard time saying which way would be faster and which
way would be slower. Thus the only consideration I have is how
actual applications perform using ELF and a.out.
-Eric
--
"The woods are lovely, dark and deep. But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."
Path: bga.com!news.sprintlink.net!sun.cais.com!news.cais.com!cais.cais.com!
ericy
From: er...@cais.cais.com (Eric Youngdale)
Newsgroups: comp.os.linux.development
Subject: Re: Shared Libs: working toward a permanent solution?
Date: 17 Sep 1994 13:05:22 GMT
Organization: Capital Area Internet Service i...@cais.com
Lines: 34
Message-ID: <35epii$19u@news.cais.com>
References: <CONNOLLY.94Sep14103940@ulua.hal.com> <35c3kg$klg@news.cais.com>
<Cw8B6I.I62@info.swan.ac.uk>
NNTP-Posting-Host: cais.com
In article <Cw8B6I....@info.swan.ac.uk>,
>X is a poor test. Most X time is in the servers or paging unless you have
>a very fast machine - Try stuff like the crypt() performance, non disk
>bound stdio throughput tests (eg pipe based), qsort() and other big
>library routines. Also remember to evaluate the calling sequence time
>as that is very important too.
>
>0-30% slower depending on the exact code involved. Certainly not acceptable.
I tried a qsort test this morning. If I use an ELF library built
without -fomit-frame-pointer (note - the a.out libraries do use this
switch), the qsort test runs about 8.8% slower with ELF. I rebuilt the ELF
libc.so using -fomit-frame-pointer, and now the ELF qsort test runs about
3.3% slower. This is probably close to a worst case, and it is certainly
nothing close to 30%. I know that previously people had guessed something
in the 10-15% area, but it is very hard to compare until you have both
implementations running on the same platform and machine.
I am not sure, but I would guess that a pipe() type of test would
have a smaller difference - some of the time in this case will be in kernel
code, and task switching.
The performance of crypt() is probably about the same as qsort(),
but I suppose I should come up with a test program to properly benchmark it.
I am rather busy right now, so if someone has nothing better to do they could
generate the test programs - I could run them with both ELF and a.out and
compare.
-Eric
--
"The woods are lovely, dark and deep. But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!pipex!
lyra.csx.cam.ac.uk!warwick!news.shef.ac.uk!shef.ac.uk!S.Herbert
From: S.Herb...@shef.ac.uk
Newsgroups: comp.os.linux.development
Subject: Re: Shared Libs: working toward a permanent solution?
Date: Mon, 19 Sep 1994 09:16:18 GMT
Organization: University of Sheffield
Lines: 22
Message-ID: <S.Herbert.7.2E7D56E2@shef.ac.uk>
References: <CONNOLLY.94Sep14103940@ulua.hal.com> <35c3kg$klg@news.cais.com>
<Cw8B6I.I62@info.swan.ac.uk>
NNTP-Posting-Host: pc121152.shef.ac.uk
In article <Cw8B6I....@info.swan.ac.uk> iia...@iifeak.swan.ac.uk (Alan Cox) writes:
>0-30% slower depending on the exact code involved. Certainly not acceptable.
If the loss is < 5%, then the benefits to developers makes it acceptable.
The current way of building, and *maintaining* shared libraries is a
nightmare - it's impossible to predict how much the structures of a new
library will change as the library grows, making static libraries look more
attractive from the large savings in the time of the developer.
>Most programs spend >75% of their cpu time
>in the libraries so they must be fast first and featuritis can come later.
I disagree that wanting shared libraries that are a lot easier to build and
maintain through their life cycle is "featuritis".
As for speed concerns, is it not possible for the library loader to resolve
addresses in the library at load time, leaving applications to link via a
hash table? That way, extra overhead during actual run time is avoided -
you have a one-off penalty when you load the library.
Stuart
Newsgroups: comp.os.linux.development
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!pipex!warwick!uknet!
info!iialan
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Shared Libs: working toward a permanent solution?
Message-ID: <CwDEK8.3GK@info.swan.ac.uk>
Sender: n...@info.swan.ac.uk
Nntp-Posting-Host: iifeak.swan.ac.uk
Organization: Institute For Industrial Information Technology
References: <35c3kg$klg@news.cais.com> <Cw8B6I.I62@info.swan.ac.uk>
<35cnek$j2i@Venus.mcs.com>
Date: Mon, 19 Sep 1994 09:33:43 GMT
Lines: 27
In article <35cnek$...@Venus.mcs.com> macgy...@MCS.COM (MacGyver) writes:
>A question then...why do people USE ELF if it slows down the system that much?
It has several advantages
1. Its easier on those poor harrased developers who would rather ship
slow and now than fast and whenever.
2. Its library handling is much more flexible
3. On most CPU's it isnt slower. On the 68030 its often faster (and
many compilers generate PC and base relative code blocks whenever they
can even in code that doesn't need to be relocatable). On the x86 which
lacks clean PC relative addresses and easy handling of base/offset pairs
barring the segment registers its very hard to do efficient position
independant code on a large scale when you have mixed access to multiple
modules (ie stuff like libraries).
4. It's trendy at the moment. Like object oriented programs being ten
times the size but terribly trendy [Good OO programs aren't bloated BTW
before I get attacked by the smalltalk mob]
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`----------------------------'`----------------------------''
Newsgroups: comp.os.linux.development
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!EU.net!uknet!info!
iialan
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Shared Libs: working toward a permanent solution?
Message-ID: <CwF9Eq.F7q@info.swan.ac.uk>
Sender: n...@info.swan.ac.uk
Nntp-Posting-Host: iifeak.swan.ac.uk
Organization: Institute For Industrial Information Technology
References: <35c3kg$klg@news.cais.com> <Cw8B6I.I62@info.swan.ac.uk>
<S.Herbert.7.2E7D56E2@shef.ac.uk>
Date: Tue, 20 Sep 1994 09:37:37 GMT
Lines: 16
In article <S.Herbert.7.2E7D5...@shef.ac.uk> S.Herb...@shef.ac.uk writes:
>As for speed concerns, is it not possible for the library loader to resolve
>addresses in the library at load time, leaving applications to link via a
>hash table? That way, extra overhead during actual run time is avoided -
>you have a one-off penalty when you load the library.
Not if its ELF. ELF libraries are position independant. You can do some
faking and happen to avoid address clashing but one of the prices of ELF
is a slower system using PIC libraries.
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`----------------------------'`----------------------------''
Newsgroups: comp.os.linux.development
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!EU.net!uknet!info!
iialan
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Shared Libs: working toward a permanent solution?
Message-ID: <CwH5n2.43I@info.swan.ac.uk>
Sender: n...@info.swan.ac.uk
Nntp-Posting-Host: iifeak.swan.ac.uk
Organization: Institute For Industrial Information Technology
References: <35c3kg$klg@news.cais.com> <Cw8B6I.I62@info.swan.ac.uk>
<35dpmp$qih@news.cais.com>
Date: Wed, 21 Sep 1994 10:11:25 GMT
Lines: 27
In article <35dpmp$...@news.cais.com> er...@cais.cais.com (Eric Youngdale) writes:
> People keep forgetting that to achieve the current shared
>libraries that we had to add a "filter" which rewrites some of the
>assembly code and adds extra indirections to any access to global
>variables. Before we can use any register, we need to save the old one on
>the stack, and then it needs to be restored when we are through. Also,
>rewriting assembly in this way this is hard to optimize for performance,
>so I would have a hard time saying which way would be faster and which
>way would be slower. Thus the only consideration I have is how
>actual applications perform using ELF and a.out.
The timings I quoted were fixed versus elf libraries on a SYS5.3 end target.
There are real differences between PIC code and magic for global variables.
The libraries use few globals and things like SVGAlib already load these
into stacked variables early on because of the otherwise present performance
hit. If you can manage enough magic to get a 0% slowdown then you are one
up on most commercial vendors I've checked against (but that won't be the
first time the EYC has done that 8)) and I'm happy to accept it. There are
still a small number of programs I build static that I expect I will
continue to do this way - stuff like Crack that are already worst case tests
of the worst cases of the C library.
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`----------------------------'`----------------------------
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!
MathWorks.Com!yeshua.marcam.com!charnel.ecst.csuchico.edu!olivea!news.hal.COM!
halsoft.com!news.halsoft.com!connolly
From: conno...@ulua.hal.com (Dan Connolly)
Newsgroups: comp.os.linux.development
Subject: ELF-based Linux distribution?
[Was: Shared Libs: working toward a permanent solution?]
Date: 22 Sep 1994 22:44:09 GMT
Organization: HaL Software Systems, Inc.
Lines: 58
Message-ID: <CONNOLLY.94Sep22174409@ulua.hal.com>
References: <CONNOLLY.94Sep14103940@ulua.hal.com> <Cw8B6I.I62@info.swan.ac.uk>
<S.Herbert.7.2E7D56E2@shef.ac.uk>
<RICHK.94Sep21133315@netcom12.netcom.com> <35rpmn$mpg@news.cais.com>
NNTP-Posting-Host: ulua.halsoft.com
In-reply-to: ericy@cais2.cais.com's message of 22 Sep 1994 11:27:19 GMT
In article <35rpmn$...@news.cais.com> er...@cais2.cais.com (Eric Youngdale) writes:
I am not entirely unsympathetic to the complaints about loss of
performance, but to start with I just want to get vanilla ELF working and
stable. Once we reach this point, then performance enhancements can be
considered (and I do have ideas). How much trouble I go to depends upon
how bad the problem really is, and this will become evident as time
goes on. Whatever enhancements I make to improve performance will have
the following properties:
OK... so I gather ELF binaries and shared libraries are a viable
long-term solution to the current shared library foo.
In fact, it looks inevitable to me.
So here's the next question: who will be the first to support a
complete ELF-based Linux distribution? Are any of the major
distributors planning to do this?
I built the Modula-3 runtime libraries using the current shared-library
tools (that's how I got started with this thread), and I can image
that eliminating all that assembly re-writing could dramatically impact
the time it takes to compile a complete Linux distribution. Should
be quite a bit quicker.
So are there significant technical obstacles remaining, or is it
a question of mind-share now?
How many major apps have been built/tested with the ELF tools?
* Has the X386 team started messing with ELF tools?
(how do they build shared libs for other BSD-based
x86 unices like BSD386, NetBSD, FreeBSD, and the like?)
* How about the apps where nobody touches the source code
any more, like TeX?
* I heard emacs excercised some problems with the ELF tools.
Anyone care to elaborate?
* How about the networking tools -- are there any interactions?
Has anyone begun exploring?
From what I have read, the ELF tools are nearly complete. They are
exiting the ALPHA phase, and it's time for major wide-spread BETA
testing. I guess that will take a few months, and then distributors
will start to think seriously about doing an ELF-based distribution...
probably some time before next summer.
Does that sound reasonable?
Dan
--
Daniel W. Connolly "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010
<conno...@hal.com> http://www.hal.com/%7Econnolly/index.html
Newsgroups: comp.os.linux.development
From: ja...@purplet.demon.co.uk (Mike Jagdis)
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!pipex!demon!purplet!jaggy
Subject: Shared Libs: working toward a permanent solution?
Organization: FidoNet node 2:252/305 - The Purple Tentacle, Reading
Date: Sat, 17 Sep 1994 10:15:00 +0000
Message-ID: <754.2E7CAB8C@purplet.demon.co.uk>
Sender: use...@demon.co.uk
Lines: 13
* In message <CONNOLLY.94Sep14103...@ulua.hal.com>, Dan Connolly said:
DC> Hmmm... I should do some reading on ELF and the iBCS
DC> project. Is there any hope that solaris binaries will run on
DC> LINUX?
I don't see why it shouldn't be possible. The iBCS emulator can already do
SVR3 (and a whole slew of variations), SVR4 and has alpha bits for Xenix 386
and the 386 BSDs. If someone buys me Solaris I'll see what needs doing (if
anything :-) ).
Mike