From owner-svn-src-all@freebsd.org Sat Aug 10 00:18:46 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B653EADEF9 for ; Sat, 10 Aug 2019 00:18:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4652lT6cLjz4D3h for ; Sat, 10 Aug 2019 00:18:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x735.google.com with SMTP id s22so73109406qkj.12 for ; Fri, 09 Aug 2019 17:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FeqrBd7UigagxbXy0TtbM7Cp/UGvhU6JeueDZS+vpw8=; b=P811mqUIOoA8XQ4do/fws+GtcdHfldaF0+AxSI8piDFQkgs6KhImuxnoWLEmDWed/1 t8j9IblARIzH0SzVUpMxV1OUeGcgctzNzKTk63YNaIbCheodvVH4y10vKiXtOYKaqmMo sVnahoDsx0g89d+6Y9YmuG7kDsK88+yYjLTD0FxB2K13Meqadm2tAdFEzejxGVaE1Jkq nfTy48pin0yXNNUcQbhd2SkKZYAStmSCnQeHLjgAK5uOJ9aP1YoVYXjj1rmag0FpIl/H C3PoQW+rdyA5sKRNRk0BTkfuM4cgzaYkeuJQI1pYwmXKGxrtUjPpAk1P3VshdMS6PDyK 8waA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FeqrBd7UigagxbXy0TtbM7Cp/UGvhU6JeueDZS+vpw8=; b=fxXHpB/rl8bcaJj3YH3+tpses41uzqR6s5UuH0Nw4Qm6WCMNGt4/66noY9ZMHsnTEl 89MNm4IysGItmgUp8ssn5I8dHwbCq2rAiskx2jsGV/g6sSZimLtz7qErxtAyQT+zMh/g 4lA3rZB1wGhjOk3+bCpmDEXvmbYgnua8SpemW0HHJ1H/MhMHJ6gDTTlxA5/eeSIIpNTl S1bFI8BRg34t5Z73pE49xDwC7WGdX73yNqvYEoioE/XXxjscXgHcmk3RXev+vMZqdbJ+ HmiqzJSZXBPvdtEFsjXiyFIlZnizIvLXW8ldNlCiU2jnxR3oof6b/+fWtKyCK3+G5kgu ExNA== X-Gm-Message-State: APjAAAVH/0SLElvIYFFkrmkX7aC9FdcJTNUMg4w1ceYhUceaL+mqvpiw V1KjILleGnJzywTuTcAKONRw0MJqmnb5yr1Ucwzwbw== X-Google-Smtp-Source: APXvYqy4DGFCBPuuQDqIDa0t5s6VI6UF5q7j2IbmAXoL75gU/MRgbr8TRLVGPPlMFwKQ+UBTUofwINuo7NyTtIDqJT8= X-Received: by 2002:a37:c87:: with SMTP id 129mr19221533qkm.240.1565396323984; Fri, 09 Aug 2019 17:18:43 -0700 (PDT) MIME-Version: 1.0 References: <201908081748.x78Hm79V085760@repo.freebsd.org> <20190808225947.GD1531@FreeBSD.org> <20190809065733.GI2731@kib.kiev.ua> <20190809210505.GJ2731@kib.kiev.ua> In-Reply-To: <20190809210505.GJ2731@kib.kiev.ua> From: Warner Losh Date: Fri, 9 Aug 2019 18:18:32 -0600 Message-ID: Subject: Re: svn commit: r350764 - head/sys/arm64/arm64 To: Konstantin Belousov Cc: Gleb Smirnoff , Warner Losh , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 4652lT6cLjz4D3h X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=P811mqUI; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::735) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-4.97 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-all@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; RCVD_IN_DNSWL_NONE(0.00)[5.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.98)[ip: (-9.45), ipnet: 2607:f8b0::/32(-2.98), asn: 15169(-2.40), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2019 00:18:46 -0000 On Fri, Aug 9, 2019 at 3:05 PM Konstantin Belousov wrote: > On Fri, Aug 09, 2019 at 10:01:31AM -0600, Warner Losh wrote: > > On Fri, Aug 9, 2019 at 12:57 AM Konstantin Belousov > > > wrote: > > > > > On Thu, Aug 08, 2019 at 07:38:28PM -0600, Warner Losh wrote: > > > > On Thu, Aug 8, 2019, 4:59 PM Gleb Smirnoff > 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. > I only reacted to the note about changing the signals syscalls behavior. > But the point is valid, we should not change the syscalls ABI for new > binaries when COMPAT_43 is enabled. I propose the following > https://reviews.freebsd.org/D21200 Glad I did the dumpster-diving grep then. I like your proposal for the same reasons you stated. WRT ioctl code for no IOC_OUT and size == 0, I believe that this is in > fact cannot be changed. It is enabled also under COMPAT_FREEBSD4 and > 5, and we always enable these for GENERIC. So effectively this ioctl > permissive mode is always there. > Yes. I also agree. And I honestly think it's OK. > > > > 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. > I believe amd64 is required since you have less and less chances to > usefully > run i386 kernel on modern hardware. > True. With your changes, enabling the option is much safer, and only drags in a minor amount of extra code. All but the most space starved users won't care at all about the delta in size. Warner > > 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 >