From owner-svn-src-head@FreeBSD.ORG Sat May 24 14:59:46 2014 Return-Path: Delivered-To: svn-src-head@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 414FFD10; Sat, 24 May 2014 14:59:46 +0000 (UTC) Received: from mailrelay011.isp.belgacom.be (mailrelay011.isp.belgacom.be [195.238.6.178]) by mx1.freebsd.org (Postfix) with ESMTP id 02F20222C; Sat, 24 May 2014 14:59:44 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4GAJKygFNbsXvB/2dsb2JhbABagweuWZROAYEDF3SCJQEBBTIBIyMQCw4KCSUPKh4GE4hGAddfF45SB4RAAQOZcpMogzo7 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; 24 May 2014 16:59:42 +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 s4OExf9D074611; Sat, 24 May 2014 16:59:41 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Sat, 24 May 2014 16:59:40 +0200 From: Tijl Coosemans To: Warner Losh Subject: Re: svn commit: r266553 - head/release/scripts Message-ID: <20140524165940.3c687553@kalimero.tijl.coosemans.org> In-Reply-To: References: <201405221922.s4MJM4Y9025265@svn.freebsd.org> <537F6706.6070509@freebsd.org> <20140523153619.GF72340@ivaldir.etoilebsd.net> <537F6EBC.3080008@freebsd.org> <20140523162020.GG72340@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Baptiste Daroussin , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, Glen Barber , Nathan Whitehorn , svn-src-head@FreeBSD.org 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 14:59:46 -0000 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. The advantage of the pkg scheme is that it has a formal structure. That's what makes it flexible, extensible, machine parsable, etc. I'd rather see the rest of FreeBSD adopt this scheme than that pkg would have to adopt the informal names. The use of x86 instead of i386/amd64 is part of the idea to merge more of sys/i386 and sys/amd64 into sys/x86 and eventually define MACHINE as "x86". Patterns like freebsd:9:* will probably become more prevalent when support for subpackages is added. Some of the subpackages (like documentation) will be ABI independent.