From owner-svn-src-head@FreeBSD.ORG Fri May 23 23:22:27 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 AA4C925B for ; Fri, 23 May 2014 23:22:27 +0000 (UTC) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (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 646CD2071 for ; Fri, 23 May 2014 23:22:27 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id tp5so5533083ieb.25 for ; Fri, 23 May 2014 16:22:20 -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:from:content-type:mime-version:subject :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=SteCm+eSClQsCe1oek3UqDfeHwH8wNdehU20aW9hrBc=; b=RofpZ9Wvha5h23fXcns3+amktqBuEEasWZosZwNpcl/qygybK+Kdzad1VtNxMnzOyc Vli5xVYL+mz5ILKGnAGqEiFaMU9NlNfPaF23+H1dJivDnedwU1YU51wfy57uCLEwAqnU Fc/NGibNcs9PMV9ETMz4F2enOuz5GQ0WK1YUc0df7NMJy3KZQb9PLM3GBrWFx0wJj2oT 4PEKluJceRBi7JLwNlEmsQTbT9iBiOY4DGEdPiLYyamSd5laisaGHlixuGbLol96yQ12 uHKU+E1leB1AqaFWuMWohZFZUxOplRmYnt5hj+iZnmHelvowzjg4mvwTJ0ajnK+R4paP XMig== X-Gm-Message-State: ALoCoQmNjv3FcAqKILhpJl76+1YMVWO6o+BpMyJZuCVbsVFswEEJNSDOPAxVkGOmZzWBsW1hgJIH X-Received: by 10.42.84.131 with SMTP id m3mr8006168icl.18.1400887340745; Fri, 23 May 2014 16:22:20 -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 ri2sm7515747igc.1.2014.05.23.16.22.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 May 2014 16:22:20 -0700 (PDT) Sender: Warner Losh From: Warner Losh X-Google-Original-From: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: svn commit: r266553 - head/release/scripts In-Reply-To: <8740c21d1e7467ea0e0355c5d05729c9@shatow.net> Date: Fri, 23 May 2014 17:22:26 -0600 Content-Transfer-Encoding: quoted-printable 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> <537F7976.3060705@freebsd.org> <20140523164521.GH72340@ivaldir.etoilebsd.net> <537F8153.7080808@freebsd.org> <20140523172636.GK72340@ivaldir.etoilebsd.net> <537F9AF4.1070502@freebsd.org> <20140523192701.GL72340@ivaldir.etoilebsd.net> <537FBB4E.2010409@freebsd.org> <8740c21d1e7467ea0e0355c5d05729c9@shatow.net> To: Bryan Drewery X-Mailer: Apple Mail (2.1878.2) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Baptiste Daroussin , src-committers@freebsd.org, Nathan Whitehorn 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: Fri, 23 May 2014 23:22:27 -0000 On May 23, 2014, at 3:34 PM, Bryan Drewery wrote: > On 2014-05-23 16:19, Nathan Whitehorn wrote: >> On 05/23/14 12:27, Baptiste Daroussin wrote: >>> On Fri, May 23, 2014 at 12:01:08PM -0700, Nathan Whitehorn wrote: >>>> On 05/23/14 10:26, Baptiste Daroussin wrote: >>>>> On Fri, May 23, 2014 at 10:11:47AM -0700, Nathan Whitehorn wrote: >>>>>> On 05/23/14 09:45, Baptiste Daroussin wrote: >>>>>>> On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn = wrote: >>>>>>>> On 05/23/14 09:20, 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 >>>>>>>> OABI is almost entirely dead, and will be entirely dead soon. >>>>>>> Maybe but still for now it is there and pkg has to work now >>>>>> We don't provide packages for ARM. Also, no platforms have = defaulted to >>>>>> OABI for a very long time. Not making a distinction was a = deliberate >>>>>> decision of the ARM group, since it was meant to be a clean = switchover. >>>>>>>>> - The different float abi (even if only one is supported for = now others are >>>>>>>>> being worked on) >>>>>>>> armv6 and armv6hf >>>>>>>>> - little endian vs big endian >>>>>>>> armv6 and armv6eb (though I think armv6eb support in general = has been >>>>>>>> removed from the tree, but armeb is still there) >>>>>>> what about combinaison? armv6 + eb + hf? >>>>>> That would be armv6hfeb, I assume, if FreeBSD actually supported >>>>>> big-endian ARMv6 at all, which it doesn't. >>>>>>>> These all already exist. >>>>>>>>> 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:* >>>>>>> arm was en example what about mips? >>>>>> The same. There is mips64el, mipsel, mips, mips64, etc. that go = through >>>>>> all possible combinations. This is true for all platforms and has = been >>>>>> for ages. There was a brief period (2007-2010, I think) where = some >>>>>> Tier-3 embedded platforms didn't have enough options, but that = era was >>>>>> obscure and is long past. >>>>>>>> The second one already would work, wouldn't it? Just replacing = x86:64 >>>>>>>> with amd64 won't change anything. The first has to be = outweighed by >>>>>>>> being able to reliably figure out where to fetch from without a = lookup >>>>>>>> table. >>>>>>>> We also added the kern.supported_archs sysctl last year to all = branches >>>>>>>> to enable figuring out which architectures a given running = kernel >>>>>>>> supports (e.g. amd64 and i386 on most amd64 systems). This was = designed >>>>>>>> specifically to help pkg figure out what packages it can = install. >>>>>>> I know, it means that we can switch only when freebsd 8 and 9 = are EOL which means >>>>>>> in a couple of years >>>>>> Why does it mean that? That doesn't make sense. A couple of = symlinks on >>>>>> the FTP server ensure compatibility. For the sysctl, it has been = merged >>>>>> all the back to 7. >>>>> So We can switch after 8.4 death which is a good news (except if = you say that it >>>>> is in 8.4) >>>> It means we can do it now. Very few people install i386 packages on >>>> amd64 anyway. It means people with very old releases on old = branches >>>> might face a warning in an unusual situation. Not a big deal. Since = we >>>> only provide i386 and amd64 packages anyway, this is also a trivial >>>> special case if you really want that. >>>>>>> And it defeats cross installation (which is the reason why the = ABI supported is >>>>>>> read from a binary and not from kernel) >>>>>> No. That's the point of the sysctl. >>>>> I'm speaking of installing packages in a arm chroot on a amd64 = host I will need >>>>> to know what arch could be supported by the "content" of the = chroot. >>>> uname -p in the chroot (I guess this is with qemu) should return = the >>>> right answer, just as it does with an i386 chroot. If it doesn't, >>>> something is broken in the qemu user mode support. >>> nope that is not with qemu it is basically cross buildworld, install = in a >>> destdir, install packages in that destdir which is a very common = usage that a >>> lot do expect to work >> Knowing a priori which architectures are "supported" by a chroot = based >> on ELF type of /bin/sh doesn't even work. How do you know what kernel >> will be running in there and how it will be configured? You don't. >> IA64 can -- sometimes -- run i386 binaries, for example. amd64 may or >> may not be able to run i386, depending on kernel options. >=20 > You're assuming that you would only use a chroot to RUN things. This = is > also useful for building images. Install a world into a chroot, run > pkg -c install whatever and it picks the right ABI. Just an example. >=20 >> In any case, I wouldn't really characterize this situation as = "common" >> in any sense -- and I don't even see why it applies to this >> discussion. Whatever logic calculates your own private version of >> architecture strings can calculate the correct ones. Allowing it to >> ignore the architecture optionally, just like you how you already = have >> to add flags to install in a chroot, would also work. Lots of things >> like that. This issue is basically wholly unrelated to whether you = use >> normal architecture strings or not. >> I'm perfectly happy to write 100% of the code to enable pkg to use = the >> same architecture strings that the rest of the operating system uses. >> Having private ones is just a recipe for confusion. =46rom this >> discussion, there don't seem to be any actually existing reasons why >> MACHINE_ARCH doesn't work for this. >=20 > pkg is *not* FreeBSD-specific. Is MACHINE_ARCH portable? MACHINE_ARCH needs to be the basic unit on FreeBSD. Outside of FreeBSD, = all bets are off sure, but if we don=92t have an easy way to get from = MACHINE_ARCH to the pkg string, then we=92ve already lost. What is the specific reason to not use MACHINE_ARCH? I=92ve not seen one = clearly articulated in this thread that makes any sense. Warner=