Re: [TUHS] SunOS code?

On Fri, Aug 31, 2018 at 04:34:51PM -0500, C??g wrote: 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.