From owner-svn-src-all@FreeBSD.ORG Fri May 23 23:24:42 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 BB53A983 for ; Fri, 23 May 2014 23:24:42 +0000 (UTC) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (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 7E42C209A for ; Fri, 23 May 2014 23:24:42 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id hn18so1307992igb.12 for ; Fri, 23 May 2014 16:24:36 -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=Lvo6gdEP3YCKU419VAvvk5lj4JvDBuSzF2PelOtV3GY=; b=kgZtt27T+C1o/wJahJyJrZAlA1lzIHAVOVsFlyl35jdUL6DuOG+giMHCm1NchX59X6 8MmzcUeKzX02XFrf5nTH6BqDTeYpTpXx/iQBfQU6NXTq0WnWznKRCU7q6XBCwQzjUpwU mwCxgwJ5p1L2CDQSbW0a2QieCwY3wZCZH6eFYzDdXAAxZtvWUXLS7qpp/E4TX2MnNBml Z+v8o2i9fBKhBs9dPA8pAy2gajkO7hxBwI7XToC2O9geYvTv1IN2Bk7Jq4wQ9mO4gvu4 5UG+36iAKCyxczz4DRTGOhJRRxghUgSaAztSx8krofE1VVnlVon5QNRXexQA8yubvtO+ Jdtg== X-Gm-Message-State: ALoCoQnyIlVTQhCnNYqZh2j1yYK/Wy/WOcYyH5594pbilPoXv5z3jKc99c2uzsah8KMfAFqopyzQ X-Received: by 10.43.93.5 with SMTP id bs5mr7884422icc.11.1400887476767; Fri, 23 May 2014 16:24:36 -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 nk1sm7528635igb.0.2014.05.23.16.24.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 May 2014 16:24:36 -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: <20140523232239.GA9268@ivaldir.etoilebsd.net> Date: Fri, 23 May 2014 17:24:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3D377734-1545-4958-BF52-B62DE718CF85@gmail.com> References: <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> <537FD679.6020503@freebsd.org> <20140523232239.GA9268@ivaldir.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1878.2) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers , Nathan Whitehorn , Bryan Drewery 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: Fri, 23 May 2014 23:24:42 -0000 On May 23, 2014, at 5:22 PM, Baptiste Daroussin = wrote: > On Fri, May 23, 2014 at 04:15:05PM -0700, Nathan Whitehorn wrote: >>=20 >> On 05/23/14 14:34, 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=20= >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> Is there any chance of finally switching the pkg abi=20 >>>>>>>>>>>>>> identifiers to just >>>>>>>>>>>>>> be uname -p? >>>>>>>>>>>>>> -Nathan >>>>>>>>>>>>> Keeping asking won't make it happen, I have explained a=20 >>>>>>>>>>>>> large number of time why it >>>>>>>>>>>>> happened, why it is not easy for compatibility and why = uname=20 >>>>>>>>>>>>> -p is still not >>>>>>>>>>>>> representing the ABI we do support, and what flexibility = we=20 >>>>>>>>>>>>> need that the >>>>>>>>>>>>> current string offers to us. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> if one is willing to do the work, please be my guess, just=20= >>>>>>>>>>>>> dig into the archives >>>>>>>>>>>>> and join the pkg development otherwise: no it won't happen=20= >>>>>>>>>>>>> before a while >>>>>>>>>>>>> because we have way too much work on the todo and this = item=20 >>>>>>>>>>>>> is stored at the >>>>>>>>>>>>> very end of this todo. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> regards, >>>>>>>>>>>>> Bapt >>>>>>>>>>>> I'm happy to do the work, and have volunteered now many=20 >>>>>>>>>>>> times. If uname >>>>>>>>>>>> -p does not describe the ABI fully, then uname -p needs=20 >>>>>>>>>>>> changes on the >>>>>>>>>>>> relevant platforms. Which are they? What extra flexibility=20= >>>>>>>>>>>> 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=20 >>>>>>>> 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=20 >>>>>>>> switchover. >>>>>>>>=20 >>>>>>>>>>> - The different float abi (even if only one is supported for=20= >>>>>>>>>>> now others are >>>>>>>>>>> being worked on) >>>>>>>>>> armv6 and armv6hf >>>>>>>>>>=20 >>>>>>>>>>> - little endian vs big endian >>>>>>>>>> armv6 and armv6eb (though I think armv6eb support in general=20= >>>>>>>>>> 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. >>>>>>>>=20 >>>>>>>>>> These all already exist. >>>>>>>>>>=20 >>>>>>>>>>> the extras flexibilit is being able to say this binary do=20 >>>>>>>>>>> support freebsd i386 >>>>>>>>>>> and amd64 in one key, freebsd:9:x86:*, or or all arches=20 >>>>>>>>>>> freebsd:10:* >>>>>>>>>>>=20 >>>>>>>>> arm was en example what about mips? >>>>>>>> The same. There is mips64el, mipsel, mips, mips64, etc. that go=20= >>>>>>>> through >>>>>>>> all possible combinations. This is true for all platforms and = has=20 >>>>>>>> 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=20= >>>>>>>> era was >>>>>>>> obscure and is long past. >>>>>>>>=20 >>>>>>>>>> The second one already would work, wouldn't it? Just = replacing=20 >>>>>>>>>> x86:64 >>>>>>>>>> with amd64 won't change anything. The first has to be=20 >>>>>>>>>> outweighed by >>>>>>>>>> being able to reliably figure out where to fetch from without = a=20 >>>>>>>>>> lookup >>>>>>>>>> table. >>>>>>>>>>=20 >>>>>>>>>> We also added the kern.supported_archs sysctl last year to = all=20 >>>>>>>>>> branches >>>>>>>>>> to enable figuring out which architectures a given running = kernel >>>>>>>>>> supports (e.g. amd64 and i386 on most amd64 systems). This = was=20 >>>>>>>>>> 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=20= >>>>>>>>> are EOL which means >>>>>>>>> in a couple of years >>>>>>>> Why does it mean that? That doesn't make sense. A couple of=20 >>>>>>>> symlinks on >>>>>>>> the FTP server ensure compatibility. For the sysctl, it has = been=20 >>>>>>>> merged >>>>>>>> all the back to 7. >>>>>>> So We can switch after 8.4 death which is a good news (except if=20= >>>>>>> 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. >>>>>>=20 >>>>>>>>> And it defeats cross installation (which is the reason why the=20= >>>>>>>>> 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=20= >>>>>>> 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=20 >>>>> in a >>>>> destdir, install packages in that destdir which is a very common=20= >>>>> usage that a >>>>> lot do expect to work >>>>>=20 >>>>=20 >>>> 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 >>>=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 >> No, I'm not. Suppose you make an amd64 jail and install an i386 = package=20 >> into it. That's fine (or is potentially fine anyway). But there is no=20= >> way to be sure since whether it's fine or not depends on the kernel = you=20 >> happen to run. >>=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. >>>>=20 >>>> 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? >>=20 >> Yes, of course. I think it's part of POSIX. The GNU and OS X versions = of=20 >> uname have it anyway. >>=20 >> I'm really quite mystified why you're so insistent on having your own=20= >> private ABI identifier strings. If you're really set on this, I of=20 >> course can't make you change. As you note, pkg is not something that=20= >> lives in FreeBSD and I have no power to change it. And, from this=20 >> conversation, I now strongly suspect that if I did put in the work to=20= >> fix this, my patch would be ignored or rejected. But it does mystify = me. >> -Nathan >> _______________________________________________ >> svn-src-all@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/svn-src-all >> To unsubscribe, send any mail to = "svn-src-all-unsubscribe@freebsd.org" >=20 > We are not insistant just we needed something that work and at the = time uname -p > did not, we exposed our need which really works now, dig in the code = try to have > the same with uname -p and without regression on the feature we = provide, and > with a compat/migration path and I will be more than happy, just that = is not as > easy as it sounds as exposed in that thread >=20 > I ll for sure integrate the patch if you manage to get it Baptiste, can you summarize why uname -p doesn=92t work, and perhaps we = can fix any issues identified. We use it extensively now and it is the gold = standard. If there=92s scenarios where the gold standard doesn=92t work, we need to get to the = bottom of them. Warner=