COMPAT_43 users?

[Brooks Davis]

On Wed, Aug 01, 2018 at 09:11:02AM -0700, Rodney W. Grimes wrote:
> > On Wed, Aug 01, 2018 at 11:28:53AM -0400, Mark Johnston wrote:
> > > On Wed, Aug 01, 2018 at 10:55:12AM +0300, Konstantin Belousov wrote:
> > > > On Tue, Jul 31, 2018 at 05:49:20PM -0400, Mark Johnston wrote:
> > > > > The COMPAT_43 kernel option, which enables syscall support for 4.3BSD
> > > > > binaries, hasn't been enabled in the standard kernel configs for well
> > > > > over a decade, and doesn't appear to be a dependency of any other kernel
> > > > > features.  Nonetheless, the kernel contains quite a bit of code to
> > > > > support this option.  Does anyone use it in modern versions of FreeBSD
> > > > > or have any arguments for keeping it?
> > > > 
> > > > COMPAT_43 means two things, the third part is a.out image activator.
> > > > First thing is the lcall $7.$0 syscall emulator, both on amd64 and
> > > > (surprisingly) i386, after 4/4 split.  Second thing is the syscalls
> > > > compat shims.
> > > > 
> > > > Together, all three things allow to run pre-3.x binaries on the modern
> > > > machines, including amd64. I think this is useful at least for 'waving
> > > > the flag' about our ABI compatibility guarantees, and for the historic
> > > > software reconstruction. I run 1.1.8 chroot and several old binaries
> > > > sometimes, I know that bde does, and there was at least one more user
> > > > some time ago.
> > > > 
> > > > What do you mean by a lot of code ?  Syscall compats is relatively easy.
> > > > lcall $7,$0 emulation is very non-trivial but tiny.  I do maintain this
> > > > code and do not want it to go away.
> > > 
> > > Thanks, fair enough.  The question was prompted by seeing lots of
> > > COMPAT_OLDSOCK ifdefs while working on some socket code.
> > 
> > I've had to figure out the COMPAT_OLDSOCK stuff a couple times in the
> > last few years.  The way it's implementation is weird in that it seems
> > to change the system wide socket behavior in a few cases.  It might be
> > a worthy endeavor to refactor this into alternate entry points for an
> > a.out compat layer (it's also patently absurd that you can invoke (e.g.)
> > cpuset_setdomain(2) from an a.out binary).
> 
> I do not see what that would be absurd, a.out is a binary executable
> format, nothing should stop me from doing anything from an a.out that
> I can do from a elf.  NOT being able to invoke foo(2) just because
> the binary was compiled to a.out would be absurd.

It's absurd because there is no sensible, supported path to create new
a.out binaries targeting FreeBSD 12.  IMO it would be better to limit
a.out support to syscalls supported by releases where a.out was
supported.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20180801/c22244e4/attachment.sig>