Re: Regarding the ULTRIX and OSF1 compats

Jason Thorpe <[email protected]> Sun, 10 Mar 2019 09:52:31 -0700
Newsgroups gmane.os.netbsd.ports.alpha,gmane.os.netbsd.devel.kernel,gmane.os.netbsd.ports.pmax
Message-ID <[email protected]>

> On Mar 10, 2019, at 4:16 AM, Maxime Villard <[email protected]> wrote:
>=20
> Le 10/03/2019 =C3=A0 11:25, Bj=C3=B6rn Johannesson a =C3=A9crit :
>> Hello.
>>=20
>> COMPAT_ULTRIX (mips) works fine which I recently discovered after =
shuffling
>> some disks and NetBSD8 mounted the ULTRIX disk as /
>=20
> This more likely means that it was an old UFS disk that we do support =
by
> default in our UFS/FFS code, but I hardly see how this could be =
related to
> COMPAT_ULTRIX.

No, I'm sure he actually means an old Ultrix disk.  Doing that sort of =
thing was quite common back in the early NetBSD days.  NetBSD/pmax =
supports the DECstation disk label format because that's what the boot =
ROM understands, and the NetBSD can read/write the Ultrix UFS because =
it's vanilla 4.3BSD.

> Which MIPS are you talking about by the way? Pmax I guess? Because
> COMPAT_ULTRIX is disabled on the majority of our MIPSs.
>=20
>> Not that I have terribly much use for it (except maybe maple) but I =
would
>> still like it to be kept in.
>=20
> I would tend to think that a good reason needs to go a bit farther =
than just
> "I'd like to keep it in"...

Like I said, COMPAT_ULTRIX is a very thin veneer over just a few native =
system calls.  I think it might even be less complex than COMPAT_SUNOS.  =
The vast majority of the COMPAT_ULTRIX system call table points directly =
either to native system calls or to COMPAT_43 veneers of native system =
calls.  The COMPAT_43 calls are quite well maintained, because they're =
required for several early flavors of COMPAT_NETBSD*.

> When it comes to Maple, it is already available on Linux, and we do =
have
> COMPAT_LINUX.
>=20
> In fact, nowadays, the vast majority of proprietary binaries compiled =
on
> UNIX-like systems are available on Linux, and we do support Linux =
emulation,
> so we're covered for the most part.

...while that may be true, if an old Ultrix version is working for him, =
why not let it continue to work?  As I said, the maintenance burden for =
COMPAT_ULTRIX is not nearly as high as for some of the others, and for =
some of those others, people weren't even actively using them.  Here was =
have an example of a not-complicated COMPAT module being actually used =
out in the wild, so I don't think it's reasonable to remove it.

-- thorpej