Date: Fri, 9 Aug 2019 10:01:31 -0600 From: Warner Losh <imp@bsdimp.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Gleb Smirnoff <glebius@freebsd.org>, Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r350764 - head/sys/arm64/arm64 Message-ID: <CANCZdfodNPJqk5K5ckL4mWsYBwAC53J9afQFwNyhy59SNcULxg@mail.gmail.com> In-Reply-To: <20190809065733.GI2731@kib.kiev.ua> References: <201908081748.x78Hm79V085760@repo.freebsd.org> <20190808225947.GD1531@FreeBSD.org> <CANCZdfocZ6DVm7ASgMia0owvx9EPs-8NuH=bQzRZ=BXpLraQqw@mail.gmail.com> <20190809065733.GI2731@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 9, 2019 at 12:57 AM Konstantin Belousov <kostikbel@gmail.com> wrote: > On Thu, Aug 08, 2019 at 07:38:28PM -0600, Warner Losh wrote: > > On Thu, Aug 8, 2019, 4:59 PM Gleb Smirnoff <glebius@freebsd.org> wrote: > > > > > Hi, > > > > > > why do we need COMPAT_43 for arm64 at all? I can't imagine an > > > application that would require this compatibility. > > > > > > A more general question is how far in the future are we going > > > to carry COMPAT_43 for i386/amd64? > > > > > > > COMPAT_43 is a weird option. It's a combo of both sys calls and kernel > > behavior modifications. Before we thinned the ABIs we supported, it was > > necessary for them as well. The biggest behavior change is around > signals. > > It is weird to sort out and nobody has done the deep analysis to see what > > is truly unused and what is there for compat with Linux and other SysV > > systems... > I am not aware of any changes that COMPAT_43 provides for the signal > handling semantic, except a minor adjustment for interpretation of > zero-sized stack for sigaltstack(2). > The onstack stuff was what I was thinking about, but we also have code in sys_getpid() that returns the ppid in the second retval register, and similar things for getuid and getgid, It also allows ioctl numbers that have IOC_IN set, but size == 0 (these would otherwise return ENOTTY). It also turns on the COMPAT_OLDSOCK code which generally only kicks in when compat bits are set, but in one place it allows a shorter unix domain socket path length to be compatible unconditionally. The compatibility TTY stuff, at least is under COMPAT_43TTY, but that's purely ioctl translation code. The COMPAT_43 option indeed enables lcall 7,0 syscall entry emulation, > on both i386 and amd64. We are able to run FreeBSD 1.1.8 (i386) on amd64 > kernel in chroot this way. Since sometimes I get bug reports about this > stuff, there are some users of it. I believe it is important to be able > to run any FreeBSD binary for PR purposes, to wave the flag of excellent > binary compatibility we offer. > > COMPAT_43 is there to stay as far as there are people willing to maintain > it. There are more than one. > I think it's safe to retain on i386. amd64 is less clear to me, but I'd lean yes. All the other platforms I'd agree with gleb: why do we need it in the kernels by default (and maybe why do we need to support it at all)? Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfodNPJqk5K5ckL4mWsYBwAC53J9afQFwNyhy59SNcULxg>