From owner-svn-src-all@FreeBSD.ORG Sat May 24 19:07:32 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34E224D4 for ; Sat, 24 May 2014 19:07:32 +0000 (UTC) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E00C924CE for ; Sat, 24 May 2014 19:07:31 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id hl10so1812236igb.15 for ; Sat, 24 May 2014 12:07:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=HfUYsflGyomy/YDuLhU33Hooz+yAZ17EYfcHAqu9l/I=; b=V6XzmH+LfAVn8u9a/h8wFTk12DBclhPWLFNsn0ZZ2trkisJh30B8X4qkbY6nGoU63b A+UY3UYS1YiUHMGIkC4EV+cA2dAkNf9CCtWHymGUw5iuPtE+jUaGHr8YbOZvMhk/74T3 hPHRDs7nLUwMsa18sl1l848JZtph8AOThrqJzrERUMtwr7/Ct3mvbxK8/bTWvt2XPcI2 S/NK7qH6sJgdCb+u0boHAX/aPO6kJE8IfyNZhg1XHF4v2cJ8FoDjZYistDIfFM5OqUgI eN4aHi+G0+acxGR/UEs8fvzHvkzqFYKEP8ZbwzYXU/MKNzFtmikk2wOJNUJgtVDFbwef QWew== X-Gm-Message-State: ALoCoQnaTGnC0X9pcfSsFT2y++s0qXo1LihIlTywCCTQhWIUa8fCd0fW4ingUGv+4NIm5otF+BU4 X-Received: by 10.43.70.12 with SMTP id ye12mr12950971icb.46.1400958451067; Sat, 24 May 2014 12:07:31 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id v8sm13803125igk.16.2014.05.24.12.07.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 May 2014 12:07:30 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_953FF7A7-FD3A-4604-9377-1B090A8C2BE4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: svn commit: r266553 - head/release/scripts From: Warner Losh In-Reply-To: <5380EBA8.1030200@freebsd.org> Date: Sat, 24 May 2014 13:07:38 -0600 Message-Id: References: <201405221922.s4MJM4Y9025265@svn.freebsd.org> <537F6706.6070509@freebsd.org> <20140523153619.GF72340@ivaldir.etoilebsd.net> <537F6EBC.3080008@freebsd.org> <20140523162020.GG72340@ivaldir.etoilebsd.net> <20140524165940.3c687553@kalimero.tijl.coosemans.org> <5380C311.60201@freebsd.org> <20140524185345.263f230d@kalimero.tijl.coosemans.org> <1400955835.1152.323.camel@revolution.hippie.lan> <5380EBA8.1030200@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1878.2) Cc: Baptiste Daroussin , src-committers@freebsd.org, Ian Lepore , svn-src-all@freebsd.org, Glen Barber , svn-src-head@freebsd.org, Tijl Coosemans X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 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, 24 May 2014 19:07:32 -0000 --Apple-Mail=_953FF7A7-FD3A-4604-9377-1B090A8C2BE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-7 On May 24, 2014, at 12:57 PM, Nathan Whitehorn = wrote: > On 05/24/14 11:23, Ian Lepore wrote: >> On Sat, 2014-05-24 at 18:53 +0200, Tijl Coosemans wrote: >>> On Sat, 24 May 2014 09:04:33 -0700 Nathan Whitehorn wrote: >>>> On 05/24/14 07:59, Tijl Coosemans wrote: >>>>> On Fri, 23 May 2014 17:29:48 -0600 Warner Losh wrote: >>>>>> On May 23, 2014, at 10:20 AM, Baptiste Daroussin = wrote: >>>>>>> On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn = wrote: >>>>>>>> On 05/23/14 08:36, Baptiste Daroussin wrote: >>>>>>>>> On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn = wrote: >>>>>>>>>> Is there any chance of finally switching the pkg abi = identifiers to just >>>>>>>>>> be uname -p? >>>>>>>>>> -Nathan >>>>>>>>> Keeping asking won't make it happen, I have explained a large = number of time why it >>>>>>>>> happened, why it is not easy for compatibility and why uname = -p is still not >>>>>>>>> representing the ABI we do support, and what flexibility we = need that the >>>>>>>>> current string offers to us. >>>>>>>>>=20 >>>>>>>>> if one is willing to do the work, please be my guess, just dig = into the archives >>>>>>>>> and join the pkg development otherwise: no it won't happen = before a while >>>>>>>>> because we have way too much work on the todo and this item is = stored at the >>>>>>>>> very end of this todo. >>>>>>>>>=20 >>>>>>>>> regards, >>>>>>>>> Bapt >>>>>>>> I'm happy to do the work, and have volunteered now many times. = If uname >>>>>>>> -p does not describe the ABI fully, then uname -p needs changes = on the >>>>>>>> relevant platforms. Which are they? What extra flexibility does = the >>>>>>>> string give you if uname -p describes the ABI completely? >>>>>>>> -Nathan >>>>>>> just simple examples in armv6: >>>>>>> - eabi vs oabi >>>>>>> - The different float abi (even if only one is supported for now = others are >>>>>>> being worked on) >>>>>>> - little endian vs big endian >>>>>> All of those are encoded in the MACHINE_ARCH + freebsd version, = no exceptions >>>>>> on supported architectures that are tier 2 or higher. This seems = like a weak reason. >>>>>>=20 >>>>>>> the extras flexibilit is being able to say this binary do = support freebsd i386 >>>>>>> and amd64 in one key, freebsd:9:x86:*, or or all arches = freebsd:10:* >>>>>> Will there be a program to convert this new, special invention to = the standard >>>>>> that we=A2ve used for the past 20 years? If you need the = flexibility, which I=A2m not >>>>>> entirely sure I=A2ve seen a good use case for. When would you = have a x86 binary >>>>>> package? Wouldn=A2t it be either i386 or amd64? >>>>> ABI isn't just about the instruction set. It's also about the = sizes of C >>>>> types (like pointers). If I remember correctly, the pkg scheme = was chosen >>>>> to allow for ABIs like x32 which use the 64 bit instruction set = with 32 >>>>> bit pointers. MACHINE_ARCH would also be amd64 in this case. >>>> No, it wouldn't. MACHINE_ARCH would be something else (x32, = probably) in >>>> such cases. MACHINE_ARCH (and uname -p, which reports it) is the = FreeBSD >>>> ABI identifier and encodes 100% of the ABI information. This would = be >>>> true even if there is never an x32 kernel. >>> No, there's no such thing as an x32 kernel. It's an amd64 kernel = that >>> supports a second userland ABI. In C preprocessor terms they are >>> distinguished by (__amd64__ && _LP64) and (__amd64__ && !_LP64). >>> uname -p gives you the processor architecture (the __amd64__ bit) = but >>> then you can still choose the sizes of standard C types (the _LP64 = bit). >>> So far we've always had one ABI per processor architecture but this >>> is not strictly necessary. >>>=20 >> All you have to do is look at the plethora of ARM ABIs we support = (and >> the corresponding separate kernel for each) to see the falseness of = that >> last sentence. ARM variations include v4 vs v6, OABI vs EABI = (calling >> and register usage standards), hard vs soft float, little vs big = endian. >> Virtually all combinations of those are possible (there are a few = combos >> we don't support), and each one has its own MACHINE_ARCH. >>=20 >=20 > Exactly. This doesn't rely on the kernel either. The hw.machine_arch = sysctl (what uname -p returns) gives the ABI of the calling binary = rather than the kernel. So if you use a 32-bit uname (e.g. in a chroot) = on an amd64 host, you get i386. The same will be true if and when we = support a 32-bit amd64 userland -- even if there is no x32 kernel, an = x32 uname will return "x32" (or "amd32" or whatever it ends up being = called). That string will also appear in kern.supported_archs. Yes, the supported_arch sysctl is 100% based on MACHINE_ARCH names. = That=A2s why we added it: so that the packaging system could use it to = offer which packages to install. > MACHINE_ARCH completely defines the ABI, without exception, because, = as a matter of policy, that's what we have defined it to mean. If there = are any circumstances where it does not -- and none have been offered so = far -- those are simply bugs that need fixing. Also, the list of ABIs we support is exported using MACHINE_ARCH names, = Those are the standard names that we use to describe everything else ABI = in the system. If there is a pkg layer translation, then it absolutely = must support translation to/from these names in the pkg layer so that = all the scripts that cope with packages don=A2t have to have this = translation embedded in them. If the translation isn=A2t there, then = that becomes a big barrier to entry for our users. Warner --Apple-Mail=_953FF7A7-FD3A-4604-9377-1B090A8C2BE4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTgO36AAoJEGwc0Sh9sBEALjEQAK4ZgAcahpc2BmyXOX2FrAPI +XRidtgXPuNZVskfYO2zysGtJ/Fq96EN40AiPnI4xPWQgbuvpSd6D+K0SnCEEWrY c1OS20+Cs8+vKB4sHhSw7ER3PI7deBoeQSFDnmm26SFgqu+XuTQiErgLv/I/Nw1U 1ZUxNoLxgcncGgXPTThZMX7s+dCHINaLQ+yslJSdgTnEyQC/XcxDaTmMDzLoPcKp 5k17RYZW5pdMiy5IsuMQxahHAr/QN17xRUQs3IP5vV6XPXntDrXkkseKJCmSGYhA +5SDlP0ZnGWr8JWBg2RA6khwoDeZjEDvaZ8xSennwxKkpU/ZyoqmofBjk19Sgg56 bXXs3eJtV4UCdgKSr93JGgeKyQpHGAm6AOk8KfDYCHT6kcJ6/yXEx4P+tB9hk6hu mnZBBJVdGJ+mGiLnatRvZxY4fh5i4acyGk9oc1DjAiaz2m8+Qpeg3orVRmQ1qubQ Z+k8FTT8mD94/BURfpPbj9gH7gRY/9MYz5m+5rukqEqNQDv8Xx3gBGkRNXR0B2/d Xnla0vJ4jkw/+x/UnvW1NOIQkCT5hxjNFPvd8FdoY5pIqOnzQYsc0TOV90XlAd6D n7eNmGFQzdvSNK2e2BlGyXht6OqgEXxZphE9oWFljIiqR6E/i6V8Nw12MD8TF4Ev C5eG5i0rQBlScdppByqZ =vr3k -----END PGP SIGNATURE----- --Apple-Mail=_953FF7A7-FD3A-4604-9377-1B090A8C2BE4--