The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: lm@bitmover.com (Larry McVoy)
Subject: [TUHS] SVR4 x86 -- Sources
Date: Tue, 19 Jul 2011 17:42:26 -0700	[thread overview]
Message-ID: <20110720004226.GA26439@bitmover.com> (raw)
In-Reply-To: <20110719231741.GA67427@geeks.org>

> There's both the STREAMS API (more properly XTI/TPI) and the STREAMS
> Kernel network processing paths. XTI/TPI have died by the wayside
> surplanted by the Sockets API, but the STREAMS kernel stuff is still
> very much part of Solaris. To me, it seemed like Sun never really gave
> all that it did for the streams kernel stuff back into SVR4, but alot
> of the networking code seemed to be an early draft of what Solaris did
> with it. Any SVR4 varients still ran with the streams networking kernel code.

This is correct, I'm intimately familiar with that STREAMS networking 
stack, it came from Lachman and I ported it twice, to the ETA 10 and
SCO.  If anyone cares, http://www.mcvoy.com/lm/sw.shar is a "streams
watch" package I wrote (and SCO shipped, at least for a while) that 
let you see the resources being used by the kernel for the networking
stack.

The Sun code was a purchase of Lachman's code.  That didn't last long
because of the terms of the purchase, then my memory is Sun did their
own stuff and then eventually contracted a rewrite out to the Mentat
folks.  If anyone cares, I just went canoeing with one the main 
networking engineers at Sun at the time and I can get the exact 
details.

The whole SVR4/STREAMS thing was a frigging mess, sockets were a much
superior model and they eventually came back.

> > Also as I understand it, SunOS was a BSD which had heaps of
> > development and original ideas put into it (shared libraries I think
> > is one example),
> 
> Yes SunOS was definately 4.xBSD and had lots of research and
> innovation I think. The big Sun Whitepaper book of research papers is 
> pretty interesting reading.

Shared libaries, loadable modules, VFS, NFS, mmap all came from Sun.

> >  but was discarded as a political decision because
> > AT&T had managed to convince most corporate customers that BSD was
> > merely a hack and SysV was the "real unix", so Sun decided to create
> > Solaris instead by licensing SysV as a starting point, I may have
> > things slightly backward so I would appreciate if anyone can confirm
> > this?

This is wrong.  Sun needed money and AT&T agreed to buy stock at over
market but the terms of the deal was that Sun had to dump SunOS and 
use SVR4 instead.  It was a horrible decision and one that I spent
almost a year fighting full time.  I took SunOS and removed all 
encumbered source from the kernel and had a kernel that booted and
ran almost all applications (there were some tty drivers that didn't
work for some 3rd party cards, stuff like that, but for 99% of the
stuff you couldn't tell it wasn't the regular SunOS).  I wrote up a
paper about all this, trying to get Sun to give that kernel away
as open source:

http://www.bitmover.com/lm/papers/srcos.html

> Sun and AT&T were partners developing SVR4 to some extent. Some of
> Sun's tech went into SVR4 (based on their 4BSD based SunOS). To me, as
> an outsider, it seemed Sun kept alot of tech to itself and rolled it
> into Solaris. 

Yup.

> But once Solaris actually became usable, it certainly did
> rock a lot more than SunOS on the hardware it was tweaked for.

SunOS would have worked fine and was a much, much, MUCH better starting
point.  We had it working on multi processors and the underlying code
would have been easier to make scale than that steaming pile of crap
that was SVR4.

If I had been successful getting SunOS out as open source, Linux wouldn't
exist, we'd all be running SunOS.  I tried.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com



  reply	other threads:[~2011-07-20  0:42 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-11 10:29 Michele Ghisolfo
2011-07-11 12:42 ` Michael Kerpan
2011-07-11 12:53   ` Jim Capp
2011-07-14 17:42     ` Al Kossow
2011-07-14 17:46       ` Jason Stevens
2011-07-15  4:10         ` Random832
2011-07-15  4:22           ` John Cowan
2011-07-12  7:54   ` Wesley Parish
2011-07-12  9:53     ` Nick Downing
2011-07-19 23:17       ` Doug McIntyre
2011-07-20  0:42         ` Larry McVoy [this message]
2011-07-20  3:16         ` John Cowan
2011-07-20  4:04           ` Warner Losh
2011-07-12  9:57     ` Nick Downing
2011-07-12 11:22       ` Tim Bradshaw
2011-07-12 11:54         ` Nick Downing
2011-07-11 12:50 ` Sergio Aguayo
     [not found] ` <4E1B6A45.40607@laposte.net>
2011-07-11 19:50   ` Michele Ghisolfo
2011-07-11 21:56     ` Jason Stevens
2011-07-11 20:08       ` Michele Ghisolfo
2011-07-11 22:56         ` Warren Toomey
2011-07-12 13:04       ` Milo Velimirović
2011-07-12 13:07         ` Jason Stevens
     [not found] <1310385759.2145.18.camel@localhost.localdomain>
2011-07-11 14:09 ` Sergio Aguayo
2011-07-12 13:24 Norman Wilson
2011-07-12 15:11 Michele Ghisolfo
2011-07-12 23:26 ` Larry McVoy
2011-07-13  0:23   ` Jason Stevens
2011-07-13 13:25     ` Arno Griffioen
2011-07-13  2:48   ` John Cowan
2011-07-13  3:07     ` Larry McVoy
2011-07-14 17:37   ` Al Kossow
2011-07-15  4:30 ` Warren Toomey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110720004226.GA26439@bitmover.com \
    --to=lm@bitmover.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).