Re: Regarding the ULTRIX and OSF1 compats

[Jason Thorpe <thorpej%me.com@localhost>]

> On Mar 16, 2019, at 5:09 AM, maya%netbsd.org@localhost wrote:
> 
> Most likely, COMPAT_ULTRIX and COMPAT_OSF1 have the same type of bugs
> that we have seen in compatibility layers elsewhere.
> Is it worth his time to test them?

Folks, PLEASE.  This is a point I've tried to make repeatedly...

These need to be taken on a case-by-case basis.

Go actually LOOK at the code in sys/compat/ultrix.

Now, go actually LOOK at the code in sys/compat/osf1.

COMPAT_ULTRIX is very simple, because Ultrix was largely a plain vanilla 4.3BSD.  It is known to be able to run commercial applications that were available for Ultrix (heck, even practically the entire Ultrix user land if you mount an Ultrix file system as root!)

COMPAT_OSF1 is not very simple, because it was Mach + some BSD bits + other random OSF stuff.  It is known to be incomplete due to lack of implementation of any of the Mach traps.  Its primary usefulness was during the early days of NetBSD/alpha.  Its usefulness is fundamentally limited by the fact that it will never be able to run threaded OSF1 binaries without an implementation of the Mach calls.

They are a different class of compat layer.

This isn't the first time we've pruned compat deadwood...

7 years ago, we got rid of COMPAT_DARWIN and COMPAT_IRIX.

11 years ago, we got rid of COMPAT_HPUX.  This one was actually very useful, at one time!  I used it to run the HP-UX X server on hp300 systems because the HP frame buffer / input device support that was in the MIT sources at the time was viciously unstable.  But eventually, its utility was reduced to approximately 0, and keeping it around didn't make any sense.

What COMPAT_DARWIN, COMPAT_IRIX, and COMPAT_HPUX all had in common was a higher maintenance burden / exposure to mistakes than things like COMPAT_ULTRIX and COMPAT_SUNOS, due to the fact that they were emulating systems that were very different inside than our own system.

I feel like the COMPAT_* modules need to have a tier system the way we have for platform ports.  Tier 1 would obviously be occupied by compatibility with previous NetBSD releases, and possibly COMPAT_LINUX on x86_64.

-- thorpej