From owner-svn-src-all@FreeBSD.ORG Sat May 24 23:53:10 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88FB4A9E for ; Sat, 24 May 2014 23:53:10 +0000 (UTC) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (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 1464F28DD for ; Sat, 24 May 2014 23:53:09 +0000 (UTC) Received: by mail-ig0-f178.google.com with SMTP id hl10so1981874igb.5 for ; Sat, 24 May 2014 16:53:02 -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=4BcffB5iCu/Q3PbbLnEUh7hoxdVfaKeanYiEAo5OeY8=; b=arSgxc91CjCo8Ugrg401oR71pcMOsIL86+KEAzXaCYyzulG1fCkm2xWJ1cSNaApEP3 dgezoNKmHeVMRuVUj0glq3FqoeqMmxvvUH7o1RQrcTafASgAK/gIsKSKjq2bH2mLSqUu n1ZzkQCW8gc/hr92e2chW1NOpNOt0kjCv0+9KBzcg0TsgJ6WZuKXDj8tEHZjHw0ufRBY 5sFuC6UC0KNStVuXTZJbsF+3tbwGJG9fDf9ePTHhdXc2QDvxtaYEU3OnJ7TJ3rVGFV1D ZJ2cAZFO6g0p7J08O4C3mGVRT14c4+da73hSWLwgstXqlfnKHiSpnyRw6S79Sv2YIWIT 5/pw== X-Gm-Message-State: ALoCoQliCWtYZuz0Bznl+4kg2Q93NodMxrFFt/ZpkqjbiYvCfASCaXn5DlsDLYBFtDb+8cB6m3cI X-Received: by 10.50.122.73 with SMTP id lq9mr13052579igb.13.1400975582177; Sat, 24 May 2014 16:53:02 -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 nk1sm15390438igb.0.2014.05.24.16.53.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 May 2014 16:53:01 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_02A95910-71D2-41B1-B1EA-81D13A907F81"; 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: <20140525011307.142b41ab@kalimero.tijl.coosemans.org> Date: Sat, 24 May 2014 17:53:09 -0600 Message-Id: <3CCAFAD3-FABE-40EF-ABF9-815FE5826349@bsdimp.com> 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> <20140525011307.142b41ab@kalimero.tijl.coosemans.org> To: Tijl Coosemans X-Mailer: Apple Mail (2.1878.2) Cc: Baptiste Daroussin , src-committers@freebsd.org, Ian Lepore , svn-src-all@freebsd.org, Glen Barber , Nathan Whitehorn , svn-src-head@freebsd.org 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 23:53:10 -0000 --Apple-Mail=_02A95910-71D2-41B1-B1EA-81D13A907F81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-7 On May 24, 2014, at 5:13 PM, Tijl Coosemans wrote: > On Sat, 24 May 2014 11:57:44 -0700 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 >> Exactly. This doesn't rely on the kernel either. The hw.machine_arch=20= >> sysctl (what uname -p returns) gives the ABI of the calling binary=20 >> rather than the kernel. So if you use a 32-bit uname (e.g. in a = chroot)=20 >> on an amd64 host, you get i386. The same will be true if and when we=20= >> support a 32-bit amd64 userland -- even if there is no x32 kernel, an=20= >> x32 uname will return "x32" (or "amd32" or whatever it ends up being=20= >> called). That string will also appear in kern.supported_archs. >=20 > There isn't necessarily any chroot environment. There's one kernel, > two equally valid ABIs (ILP32 and LP64) and any binary like uname = might > use either of them. If uname -p returns a different result depending = on > which of these two ABIs it was compiled for that could be a problem = for > any script that uses it. Well, it depends on what you want to do with the script, eh? If you want = to know the ABI of the native binary uname, that=A2s one thing. But if = you want to know the supported ABIs, you are doing it wrong by using = uname. You should be using sysctl kern.supported_abi. That will tell you = all the ABIs that you can install packages for on this machine, which is = what you really want to know. So I=A2m having trouble connecting the = dots between this and what you are saying here. I still am absolutely flabbergasted why the MACHINE_ARCH names aren=A2t = necessary and sufficient for packaging. I=A2ve yet to see any coherent = reason to not use them. Warner --Apple-Mail=_02A95910-71D2-41B1-B1EA-81D13A907F81 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 iQIcBAEBCgAGBQJTgTDlAAoJEGwc0Sh9sBEA/0YP+wff0BgZzV3tZYQiP0qp6b3I wlxdKCDQZRh0p7fcKc9+44iVkyCCzuZv0Gk97j5Y3sDZNIu5oU5uwR0X9Nsbt/Rp stbDMbv36fPsM6Kj7C07Ugb5ElN9gH/UulO9Vm3RqCL1tZJO35w/MXWwBDzZHZw8 TySBj2WUaSaFmgYGLmBv2X6sJJfEmYMl9GcC2TUpdEPfNLu5xNgDECmuO9uOmbSh aRO5pFRnprWkwWfv0PuXrBBkVJevgcWzq5euylIVfs85XTNmNugflJzQfYXiI5qx GBnJbXgI6B95qFIg37g95zKI35Ny591jy9X2oYpinYNxlhv2pRFjFlJD+liWtB0z Wpp7OnaWO1FxpQS+lSaqbjNPrJ9eLTpNMMenwXEU567t5w9P4pRjAUW/o8eFqbCj wHiRaaRAIJ5qEewF8sW33975gRufMy64ASnXCosz5RUG9wDTcXlQ5G+JiGwMo9BA 5fuEHlkHzpWZ3sCV4PfOYqWUH0Dy6YbZ74gfXI92QbyCq/4/TANG85fNC8DzZ14e FgE5WqhRzrBVJmoFFW+lQly/YV2i2Akh8xt3WqDEhPmppMCQ3uA0fGK4n7PXNmIK 2hc/E+qbMMoImT3sQ9rfVXanTCXoHdGNt+G06/C8b5d9jseElQuvuWUFeqCYq6iC TAy0uy04ejLfGBFICSb/ =Xm3M -----END PGP SIGNATURE----- --Apple-Mail=_02A95910-71D2-41B1-B1EA-81D13A907F81--