[TUHS] SunOS code?

Larry McVoy lm at mcvoy.com
Sat Sep 1 07:58:54 AEST 2018


On Fri, Aug 31, 2018 at 04:34:51PM -0500, C??g wrote:
> Kevin Bowling wrote:
> 
> > Sun releasing OpenSolaris when they finally did and under the CDDL was
> > pretty tone deaf to what was going on in the market with Linux, but
> > you have to admire the amount of contract review and legal work that
> > must have taken.
> 
> How is OpenSolaris different from SunOS (Sun/Oracle Solaris) anyway?
> Isn't the relationship kinda RHEL-CentOS'ish? I.e. one is community-
> -supported, and another is commercially.

SunOS was based on the BSD code, the entire system was frequently
described as "a bug fixed BSD".  It was, of course, a lot more than that,
Sun dis shared libs, a new (much, much better) VM system, invented the
vnode interface that virtualized file systems, BSD had none of that.

Lots of Usenix papers describing that work here:

SunOS felt very much like BSD, all the stuff you thought would work,
usually did, the user space was very BSD like.

http://mcvoy.com/lm/papers/

Solaris was Sys Vr4 (which, if I recall correctly, differed from r3
largely due to some stuff being ported over from SunOS).  Both the kernel
and user space went to a Sys V compat system, it no longer felt anything
like BSD.

So why would Sun take something that everyone loved and replace it
with that steaming pile of Sys V garbage?  Only the top execs actually
knew the real reason, I'm 99% sure my boss, Ken Okin (VP of all server
hardware), did not know the real reason.  Which was, Sun was in some
financial trouble, I don't know the details, but AT&T bought $200M of
Sun stock at 35% over market to bail them out.  In return, Sun had to
drop SunOS and go with Sys V.  AT&T was betting that Sun would make Sys
V as popular as SunOS.

Didn't happen.  Not even close.  A lot of people just bailed, trying to
work with Sys V was miserable.  It put us backwards at least 10 years and
I'd argue more than that.  The engineers loved SunOS and tons of work
got done on the system that management never asked for, the engineers
really drove the agenda.  When all that work was yanked away, it took
the heart out of engineering.

A bunch of people stuck around and tried, they really did and I applaud
them for it but the damage was done.  I was gone by the time ZFS came out
so I have no idea how that passed through the formal vetting process that
Sun had in place.  When I was there, if I had proposed a file system that
wouldn't use the page cache, you'd have to copy from the buffer cache
into the page cache to get mmap to work, I would have been kicked out
of the room and probably kicked out of the kernel group.  We had spent
SO FRIGGING MUCH TIME getting rid of the buffer cache, precisely because
trying to maintain coherency between the page cache (mmap) and the buffer
cache (read/write), it was clear that you wanted a unified model.

Yet the wise heads in charge approved ZFS.  It boggles my mind.  Yeah,
I get it, it's got lots of nice features.  But at the expense of breaking
one of the cornerstones of the kernel design.

The only thing I can think of is that the people who could see the whole
kernel architecture had left, I can't imagine Kleiman, Gingell, Rosenthal,
Powell, any of the old school distinguished engineers, tolerating that
for 1 second.  So my guess is they were gone and nobody in the vetting
process saw the whole picture any more.

If anyone is lurking on the list and was there for the ZFS work, I'd
love to hear your take on it.  I'm speculating.  It just blows my mind
that something that was one of the main design points for the previous
10-15 years, was ignored.  We're not talking about some obscure device
driver, we're talking about mmap(), which was one of the reasons Sun ran
circles around the other guys, they all had crappy mmap() implementations
that copied.  ZFS went back to that.  Weird.



More information about the TUHS mailing list