[TUHS] CMU Mach sources?

Larry McVoy lm at mcvoy.com
Tue Jun 25 10:06:30 AEST 2019


All interesting points but messy code is messy code.  I had a bunch of the
FreeBSD folks over here for a BBQ a couple days ago (they want you at the
next one Clem).  We got to talking about Mach and someone told me that in
the FreeBSD tree the Mach code was gone through and 60% of was deleted and
it still worked.  It just seems like the Mach folks wanted to try this,
and that, and then next thing and never went back to clean up the mess.

Even after that FreeBSD cleanup the code looks like crap to me.  Let me
define "crap" by defining good code.  Good code is very stylized, you
learn part of the system and you get the style and you can predict what
the next part of the system looks like and when you get there, yeah,
the prediction and the code matches.  That's what SunOS 4.x was like
when I sort of "got it".  I just guessed what I'd see and that was 
what I saw.

The Mach code, IMHO, completely fails that test.  You can't predict 
anything, there are layers of code that don't seem to do anything,
you have to tag through them to get to the code that does something.
There are all sorts of helper functions (after the cleanup!) that
don't seem to be used.

I get that it was a big effort and I get that it was research code, 
but Clem, I can point you to code that I wrote as a grad student
and it is SunOS like.  You can predict what stuff looks like.  

That's just clean code.  Mach was never like that, I'm sorry, but
it wasn't.  

Was it/is it useful?  Yeah.  Would I like to work in that code if I had
the juice?  No, hard pass.  And I was in it recently enough to submit
a patch to the FreeBSD tree, trivial patch but you have to read a bunch
of code to get to that trivial patch.  It wasn't fun reading that code.
Maybe I'm just old and washed up but maybe I know clean code when I see
it.

On Sun, Jun 23, 2019 at 09:52:33PM +0000, Clem Cole wrote:
> A couple of thoughts...
> 
> 1.) Mach2.5 and 3.0 was part of an *extremely successful research project*
> but also did suffer from issues associated with being so.  CSRG BTW *was
> not a research project*, contrary to its name, it was a support contract
> for DARPA since BTL would not support UNIX the way DEC, IBM, *et al*, did
> with their products.   The reality is that Mach more than Thoth**), V
> Kernel, QNX, Sol, Chrous, Minux or any other uK of the day, changed the way
> people started to think about building an OS.    Give Rashid and team
> credit - it showed some extremely interesting and aggressive ideas could be
> made to work.
> 
> 2.) Comparing Mach with BSD or SunOS 4.3 is not really a valid comparison.
>  They had different goals and targets.   Comparing Ultrix, Tru64, or Mac
> OSx with SunOS (or Solaris for that matter) is fair.   They all were
> products.  They needed to be clean, maintainable and extensible [as Larry
> likes to point out, Sun traded a great deal of that away for political
> reasons with Solaris].   But the bottom line, you are comparing a test
> vehicle to a production one.  And I while I agree with Larry on the
> internals and a lot of the actual code in Mach, I was always pretty damned
> impressed with what they crammed into a 5 lbs bag in a very short time.
> 
> 3.) Mach2.5/386/Vax/etc.. << OSF/1 386 the later is similar what MtUnix
> shipped.  Both are 'hybrid' kernels.   But while MtUnix created a product
> with it, they were too small to do what DEC would later do.   But the
> investment was greater than I think they could really afford.
> 
> 4.) Mach 3.0 was from CMU, Mach 4.0 (which is still sort of available) was
> from the OSF/1 [this is a pure uK].
> 
> 3.) DEC OSF/1 (for MIPS) << Tru64 (for Alpha) - *a.k.a.* Digital UNIX - yes
> both started with a Mach 2.5 hybrid kernel and the later was mostly the
> same as OSF/1386, and both supported the Mach2.5 kernel message system -
> but DEC's team rewrote darned near everything in the kernel -- which in
> fact was both a bless and a curse [more in a minute].
> 
> Ok, so why have I bothered with all this mess.   The fact is Mach was able
> to be turned into a product, both Apple and DEC did it.   Apple had the
> advantage of starting with NextOS which (along with machTen) was the first
> short at making a 'product' out of it.  But they invested a lot over the
> years and incrementally changed it.  Enough to create XNU.    DEC was a
> different story (which I lived a bit of personally).
> 
> The DEC PMAX (mips) and the Intel 386 were the first references from OSF.
>  OSF had an issue.  IBM was supposed to deliver an OS, but for a number of
> reasons was not ready when OSF needed something.   CMU had something that
> was 'good enough.'
> 
> This is probably where Larry and I differ a little on shipping code.  I'm a
> great believer figure out one solid goal and nailing it, and the rest is
> 'good enough' - i.e. fix in version 2.   I think OSF/1 as a reference
> system nailed it.   Their job was get something out as a starting base that
> ran on at least 2 workstations (and one server - which IIRC was an HP,
> maybe an Encore box) but able to be shipped on an AT&T V.3 unlimited
> license [which IBM had brought to the table].   The fact that they did not
> spend a lot of time cleaning up about CMU at this stage was not their job.
>  The kernel had to be good enough - and it was (Larry might argue Mach2.5
> vs SunOS 4.3 it was not as good technically - and he might be right - but
> that was not their job).
> 
> So DEC gets a new code based.  They have Ultrix (a product) for the PMAX.
> OSF has released the reference port.   From a kernel code quality
> standpoint, OSF1 1.0/PMAX < Ultrix/RISC 4.5.   They also are moving to a
> new 64-bit processor that is not going to run either VAX or PMAX binaries (
> *i.e.* you will have to recompile).   Two technical decisions and one
> marketing one were made at the management level that would later doom
> Tru64.   First, it was agreed that Tru64 was going to be 'pure 64-bit' and
> it turned out >>none of the ISVs had clean code.  Moreover, there were no
> tools to help find 64-bit issues.  This single choice cost DEC 3 years in
> the ability to ship Tru64/Alpha.   The second choice was DEC's team decided
> to re-write OSF/1 subsystem by subsystem.   The argument would be:  the XXX
> system sucks.  It will never scale on a 64-bit system and it will not work
> for clusters.  XXX was at least Memory Management, Terminal Handler, Basic
> I/O, SCSI, File System.  The >>truth<< is each of these was actually right
> in the small, they did suck.   But the fact is, they all were good enough
> to get the system out the door and get customers and ISV's starting the
> process of using the system.   Yes, Megasafe is an excellent FS, but UFS
> was good enough to start.   The marketing decision BTW, that not to ship
> Tru64/PMAX.   Truth is it was running internally.  But Marketing held that
> Tru64 was the sexy cool thing and did not want to make it available.  The
> argument was they would have to support it.   But the truth is that asking
> ISV's and customers to switch Architecture and OS in one jump, opened the
> door to consider Sun or HP (and with Tru64/Alpha's ecosystem taking 3 more
> years, people left DEC).
> 
> 
> 
> 
> 
> ** Mike Malcolm was the primary author of Thoth as his PhD from Waterloo.
> HIs officemate, Kelly Booth (of the 'Graphics Killer-Bs) had a tee-shirt
> made that exhaled:  'Thoth Thucks' and gave them to the lot of the Waterloo
> folks.   BTW, Mike and Cheridon would later go to Stanford and create V.
>  Two of their students would create QNX with still lives.
> 
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


More information about the TUHS mailing list