From owner-svn-src-head@freebsd.org Thu Nov 21 06:28:29 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 F1EA91AFFA9 for ; Thu, 21 Nov 2019 06:28:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 47JV4X6dLNz3Qk0 for ; Thu, 21 Nov 2019 06:28:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82e.google.com with SMTP id i17so2530795qtq.1 for ; Wed, 20 Nov 2019 22:28:28 -0800 (PST) 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=WzVtbKm6TR3zrjsZv1jMKAKIPgXfrDr49t4GoSRhSes=; b=Z9BoU+1QFmS8nh7ose3bmUkwPKdcbz0TKmc5ZtS8GjD5u5wVloCl5uAU+2q1QFP4XW e1a455xhU1MGsQfucJb6+lg6hamJlVOo1E6TVnbbXy+sCPruGAa6xJ4JgJpd9ajo5FnQ 6dExdwTnsMhZCicmwtWMGAqJAVGXLSFtSl5C+KCiBEn4MMMQ9TLo0H2dFEsMuQhsvc0W YLcr8Rbm1oIZDaojZvpNwF7qlmzG11eCr2ju91/003Hh1OxI0Xb/1AZvrMnsypTHbZ3u oIHZjmXCkjNH+rQN6GTDEjUlavyus6CiJLygS5NxUoB/LU5b3GmF+SW3wiFlHxDms3yp zaAQ== 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=WzVtbKm6TR3zrjsZv1jMKAKIPgXfrDr49t4GoSRhSes=; b=SuUiKki+TrBeHE6+m9zSFhSybEsZPinnOJNny06ky74xj9LhT5ljgSy9ocj3BJLnEp wJpjbB0dba8bz/iZ9F0H/wxfxQfephh5TxrNkZSuaXQcB2FCmkvmfsf3FHUlv5M1vHQD g7kSGpJdOoLPJAMy7AnWUNG/Z2+x1GhXoYjog4udZbE7HOhR9CBx4YHOyYMM/v7diTsH xGk46/fWqDTcGsHcPFc93csimBnVhavqldTcw/zeFgxgMvUl3sTLOzn6tegq029qyhvu BEhzPVfiNF+obbcHqrez5qWifqnA1Af+dI+/ErHNGB0RWGYzFF6HgDgEBV3eC/Df7ca7 8QLw== X-Gm-Message-State: APjAAAWnEdn6/xK9bMtgMRXHiqZu+Cr0Nh+oXnSMPpYS5FNNZf5gdkZR Hr2ovcH8C138GvBI0Rvk4GAyUgIbnzT1f4f1LwwDEg== X-Google-Smtp-Source: APXvYqzXcKRlcz0VW5rtyZx6Bd9kp1o7n2fSua8qfywKocOniCouIa37giHRogUXEK2J1bEJr2nzPUk6a5ZivtYUnik= X-Received: by 2002:ac8:754c:: with SMTP id b12mr6927242qtr.291.1574317707322; Wed, 20 Nov 2019 22:28:27 -0800 (PST) MIME-Version: 1.0 References: <201911201654.xAKGsMTv094014@repo.freebsd.org> <59bf120c-2f35-1a22-b6fa-a9c9bb8cfdf4@FreeBSD.org> <991bdc33-516d-6e6d-1880-44930441893d@FreeBSD.org> In-Reply-To: <991bdc33-516d-6e6d-1880-44930441893d@FreeBSD.org> From: Warner Losh Date: Wed, 20 Nov 2019 23:28:16 -0700 Message-ID: Subject: Re: svn commit: r354900 - head/usr.sbin/jail To: John Baldwin Cc: Li-Wen Hsu , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 47JV4X6dLNz3Qk0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=Z9BoU+1Q; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::82e) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-4.71 / 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)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[e.2.8.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]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.71)[ip: (-9.26), ipnet: 2607:f8b0::/32(-2.29), asn: 15169(-1.97), 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: Thu, 21 Nov 2019 06:28:30 -0000 On Wed, Nov 20, 2019 at 4:32 PM John Baldwin wrote: > On 11/20/19 3:04 PM, Warner Losh wrote: > > On Wed, Nov 20, 2019 at 3:09 PM John Baldwin wrote: > > > >> On 11/20/19 10:01 AM, Warner Losh wrote: > >>> On Wed, Nov 20, 2019 at 9:54 AM Li-Wen Hsu wrote: > >>> > >>>> Author: lwhsu > >>>> Date: Wed Nov 20 16:54:21 2019 > >>>> New Revision: 354900 > >>>> URL: https://svnweb.freebsd.org/changeset/base/354900 > >>>> > >>>> Log: > >>>> Use the correct variable, also limit the scope to bfd > >>>> > >>>> PR: 242109 > >>>> Reported by: jhb > >>>> Sponsored by: The FreeBSD Foundation > >>>> > >>>> Modified: > >>>> head/usr.sbin/jail/Makefile > >>>> > >>>> Modified: head/usr.sbin/jail/Makefile > >>>> > >>>> > >> > ============================================================================== > >>>> --- head/usr.sbin/jail/Makefile Wed Nov 20 16:35:58 2019 > >> (r354899) > >>>> +++ head/usr.sbin/jail/Makefile Wed Nov 20 16:54:21 2019 > >> (r354900) > >>>> @@ -18,7 +18,7 @@ CFLAGS+=-I. -I${.CURDIR} > >>>> # workaround for GNU ld (GNU Binutils) 2.33.1: > >>>> # relocation truncated to fit: R_RISCV_GPREL_I against `.LANCHOR2' > >>>> # https://bugs.freebsd.org/242109 > >>>> -.if ${MACHINE_ARCH} == "riscv" > >>>> +.if ${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv" > >>>> > >>> > >>> MACHINE isn't the right thing to use here. It's never the proper thing > in > >>> userland makefiles, unless they are interfacing with the kernel. > >>> > >>> MACHINE_CPUARCH is what you want here. > >> > >> Eh, that claim doesn't seem quite true. src.opts.mk only uses MACHINE > >> and not > >> MACHINE_CPUARCH for example (to set _TT that is then used all over the > >> place in src.opts.mk). My experience is that uses of *_CPUARCH are in > >> fact > >> pretty rare. > >> > > > > However, __TT is used bogusly in many places in src.opts.mk. They are > all > > relatively new related to llvm (and one for google test). MACHINE has > > always been for the kernel and MACHINE_ARCH for userland. MACHINE_CPUARCH > > was created for those architectures where we have a number of > MACHINE_ARCH > > to make things easier to cope with. > > > > I've done several sweeps of the tree over the years to keep this > enforced, > > so I'm quite sure of the dichotomy... > > Here are some to fix then: :) > > sbin/reboot/Makefile:.if exists(${.CURDIR}/boot_${MACHINE}.8) > sbin/reboot/Makefile:MAN+= boot_${MACHINE}.8 > sbin/reboot/Makefile:MLINKS+= boot_${MACHINE}.8 boot.8 > sbin/reboot/Makefile:.if ${MACHINE} == "amd64" > usr.sbin/bsdinstall/partedit/Makefile:PARTEDIT_ARCH= ${MACHINE} > usr.sbin/bsdinstall/partedit/Makefile:.if ${MACHINE} == "i386" || > ${MACHINE} == "amd64" > usr.sbin/pkg/Makefile:. if ${MACHINE} != "amd64" && ${MACHINE} != "i386" > I'm not sure these are wrong... reboot is based on the kernel we're running, though. partedit is based on what kind of partition scheme the kernel wants. pkg is just wrong, though. Traditionally in BSD, different ways of booting usually went hand and hand with needing different kernels. Though after BSD passed from mini/micro computers where this was true into embedded things got blurrier. Likewise with the partitioning schemes: those used to be different for every type of computer, but now have standardized around GPT with a few legacy systems like MBR and APM lingering on. BSD labels were originally invented to have a standard way to label a disk, but even that grew a lot of variations. > This one also seems dubious, but in a different way: > > usr.bin/Makefile: > > # ARM64TODO gprof does not build > # RISCVTODO gprof does not build > .if ${MACHINE_ARCH} != "aarch64" && ${MACHINE_CPUARCH} != "riscv" > SUBDIR.${MK_TOOLCHAIN}+= gprof > .endif > Yes. That's likely incorrect. > Somewhat exacerbated by the whole aarch64 vs arm64 thing and probably confusion on when to use CPUARCH vs ARCH. When I invented CPUARCH, I didn't make it as clean as I'd like. It's always for 'what directory do we use in the tree' and is also convenient for other things. It was thought you'd use CPUARCH when you are testing generically for an arch. You'd use MACHINE_ARCH when you needed a specific one (so both of these should be MACHINE_CPUARCH). The notion was you'd only need to use MACHINE_ARCH rarely in ifdefs and usually only inside of system-wide .mk files. > BTW, MACHINE_ARCH seems to matter just as much for the kernel. 64-bit > mips runs a "mips64" kernel, not a "mips" kernel. > It does. With PC-98 removed, I don't think we have any cases where MACHINE != > MACHINE_CPUARCH now? > Well, there's arm64 / aarch64. I'm not at all opposed to changing the definitions, but they are what I've been saying. I've done a lot of cleanup of mis-uses over the last 10 or 15 years, so these characterizations are correct. I'll admit I've done not the best job at documenting it, though. Coming up with new definitions is fraught, I'd think, since it's easy to have a notion of what the right thing is, but harder to cast it into good prose that's clear to a wide audience. Warner