From owner-svn-src-head@FreeBSD.ORG Sat May 24 23:13:20 2014 Return-Path: Delivered-To: svn-src-head@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 86674121; Sat, 24 May 2014 23:13:20 +0000 (UTC) Received: from mailrelay009.isp.belgacom.be (mailrelay009.isp.belgacom.be [195.238.6.176]) by mx1.freebsd.org (Postfix) with ESMTP id 213FE265F; Sat, 24 May 2014 23:13:18 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQGANkmgVNbsXvB/2dsb2JhbABYgweBHa0+lE4BgQMXdIIlAQEFViMQCw4EBgklDyoQDgYTiEYB11YXjh8zB4RAAQOZcpMogzo7 Received: from 193.123-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.123.193]) by relay.skynet.be with ESMTP; 25 May 2014 01:13:10 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.8/8.14.8) with ESMTP id s4OND8J6084381; Sun, 25 May 2014 01:13:08 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Sun, 25 May 2014 01:13:07 +0200 From: Tijl Coosemans To: Nathan Whitehorn Subject: Re: svn commit: r266553 - head/release/scripts Message-ID: <20140525011307.142b41ab@kalimero.tijl.coosemans.org> In-Reply-To: <5380EBA8.1030200@freebsd.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Cc: Baptiste Daroussin , src-committers@freebsd.org, Ian Lepore , svn-src-all@freebsd.org, Glen Barber , svn-src-head@freebsd.org, Warner Losh X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 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: Sat, 24 May 2014 23:13:20 -0000 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 num= ber of time why it >>>>>>>>> happened, why it is not easy for compatibility and why uname -p i= s still not >>>>>>>>> representing the ABI we do support, and what flexibility we need = that the >>>>>>>>> current string offers to us. >>>>>>>>> >>>>>>>>> if one is willing to do the work, please be my guess, just dig in= to 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 st= ored at the >>>>>>>>> very end of this todo. >>>>>>>>> >>>>>>>>> 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 ot= hers are >>>>>>> being worked on) >>>>>>> - little endian vs big endian >>>>>> All of those are encoded in the MACHINE_ARCH + freebsd version, no e= xceptions >>>>>> on supported architectures that are tier 2 or higher. This seems lik= e a weak reason. >>>>>> >>>>>>> the extras flexibilit is being able to say this binary do support f= reebsd 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 th= e 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 c= hosen >>>>> 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 FreeB= SD >>>> 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. >> >> 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. 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.