From owner-svn-src-all@FreeBSD.ORG Sat May 24 18:57:47 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 DF980F78; Sat, 24 May 2014 18:57:47 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 820C02401; Sat, 24 May 2014 18:57:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 985733805C; Sat, 24 May 2014 13:57:46 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id 1RoFjikIt_v1; Sat, 24 May 2014 13:57:46 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 9635F3805B; Sat, 24 May 2014 13:57:45 -0500 (CDT) Message-ID: <5380EBA8.1030200@freebsd.org> Date: Sat, 24 May 2014 11:57:44 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ian Lepore , Tijl Coosemans Subject: Re: svn commit: r266553 - head/release/scripts 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> In-Reply-To: <1400955835.1152.323.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 8bit Cc: Baptiste Daroussin , src-committers@freebsd.org, svn-src-all@freebsd.org, Glen Barber , svn-src-head@freebsd.org, Warner Losh 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 18:57:48 -0000 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. >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> 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. >>>>> >>>>>> 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˘ve used for the past 20 years? If you need the flexibility, which I˘m not >>>>> entirely sure I˘ve seen a good use case for. When would you have a x86 binary >>>>> package? Wouldn˘t 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. >> > 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. > 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. 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. -Nathan