From owner-svn-src-head@freebsd.org Fri Aug 9 16:01:44 2019 Return-Path: Delivered-To: svn-src-head@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 D730ACC2FE for ; Fri, 9 Aug 2019 16:01:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 464qk001flz3FJk for ; Fri, 9 Aug 2019 16:01:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72c.google.com with SMTP id s22so72090367qkj.12 for ; Fri, 09 Aug 2019 09:01:43 -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=uDhoE0JwbuoDIDykmP00crDCn3vaXikXj8d+jf5c2S0=; b=j1IAfECQ8ax3NkgooA3UIVqoyP2ztNltM1Z//MRS19zj7sXsdhSZnKZXV9JNJVmP0T Rjco4kzsf2irUy1o3oUE1xoba/HMlFPPnDiuyH81/0Yi/4huglBOL3BN+RnsLxFrS8i3 kDjTfJ6R68E6Al4BpNAAlBMvm6vPvX22G45q70iHTpUCRAhvKNCuH2K/m1fkPGLbVZ1r C8FBqC+GZ9H418Lp+XzHh4TFGcHtq5NfDvzxcUICKDPOsdpmO/HDjqN890JzSBmVnZeb BBs4milY4RzpqH1O9FUr8Qjnxcr0UQCicK5mjT3M8rHFCk/YH6vvHzxVTRBEdETibQEM Bkgw== 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=uDhoE0JwbuoDIDykmP00crDCn3vaXikXj8d+jf5c2S0=; b=DzoOi/xwfeyg7hgNoJ1ewLJaBiLIXauj7BS9klBBmGcKUU8JC2onhwE5Z0zDmv2/tB 9ZMDfr8zlQ2E78KvFPiY500a9desXmWXYHl/1/NOb+TVoI888+OceBqWdMlbcnN9escm gqq+oaOl4hzKL4gp3uZcAITtX34EEkNOX2VzIiIfaN6cIhbqcULK9psVYV8lHAT7pIv5 eGNC/ek7FFBGKBxxQTK5kEnHGYZQLbg0FbAiMwjfdfwLjEyqHM7pFNGKnRfgwaYmzoum jxY/uqN89ryfY/7OibtITTEwjh0HD80o3FFtVXEnXwiw3WaR7JfjZD0O1lm3E/gnw14F 84pg== X-Gm-Message-State: APjAAAWVRR6pVvwHqsTP+YNSEBB1WcanjeTEjCcrgzqZ8yUocLkxi4k4 Iz7szOnORWFBEDsYDNnY2MEdw5NPrwsB/oAD4lhqiQ== X-Google-Smtp-Source: APXvYqxaqyrFzhwZvHktcuoQnnM/0YqpRLuKo2hzWVmDGFpaB3dQ8sT7rfJTcaj7h+EN9T4s9fuhVLW5Li6ZGHV8UCw= X-Received: by 2002:a37:c87:: with SMTP id 129mr17408854qkm.240.1565366502702; Fri, 09 Aug 2019 09:01:42 -0700 (PDT) MIME-Version: 1.0 References: <201908081748.x78Hm79V085760@repo.freebsd.org> <20190808225947.GD1531@FreeBSD.org> <20190809065733.GI2731@kib.kiev.ua> In-Reply-To: <20190809065733.GI2731@kib.kiev.ua> From: Warner Losh Date: Fri, 9 Aug 2019 10:01:31 -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: 464qk001flz3FJk X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=j1IAfECQ; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::72c) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-5.95 / 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-head@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; 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(-1.00)[-0.996,0]; RCVD_IN_DNSWL_NONE(0.00)[c.2.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.96)[ip: (-9.36), 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-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 16:01:44 -0000 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. 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