Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support (fwd)

[gnats-admin%netbsd.org@localhost]

The following reply was made to PR kern/58225; it has been noted by GNATS.

From: Jason Thorpe <thorpej%me.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: pgoyette%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost,
 mlelstv%netbsd.org@localhost
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
 (fwd)
Date: Sat, 24 Aug 2024 06:39:54 -0700

 > =46rom what I can see (*) you've handled the (COMPAT_NETBSD32 & =
 COMPAT_16)
 > situation, but at the expense of mishandling (COMPAT_NETBSD32 & ! =
 COMPAT_16)=20
 > situation.  You really should not be auto-loading a module
 > that isn't desired.  As you can see, that brings in a whole lot of =
 other
 > cruft for COMPAT_* and COMPAT_NETBSD323_*.
 >=20
 > What happens if we simply don't autoload compat_netbsd32_16 module?  =
 If
 > it is loaded through other means (modload(8) maybe) then we get the
 > behaviour that you already implemented; if the module isn't loaded, we
 > should reurn EINVAL.
 
 Note the only reason I made the changes in the first place is because =
 COMPAT_NETBSD32 signal delivery was already a complicated broken mess =
 (and the changes addressed a reported bug).  Sure, more modules might =
 get loaded now, but at least signal delivery works.
 
 TBH, I don=E2=80=99t get what the big deal is here.  The NETBSD32 =
 version is doing basically what the non-NETBSD32 version is doing: that =
 is, if the process says is uses the old =E2=80=9Csigcontext=E2=80=9D =
 type of trampoline, it auto-loads the compat_16 module.  And it=E2=80=99s =
 been doing that ever since 2019 when *you* made that change.
 
 -- thorpej