Re: Regarding the ULTRIX and OSF1 compats

> On Mar 16, 2019, at 5:09 AM, [email protected] wrote:
>=20
> 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