From owner-svn-src-head@FreeBSD.ORG Fri May 23 23:22:45 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 B1E0B2BC; Fri, 23 May 2014 23:22:45 +0000 (UTC) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (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 A31482075; Fri, 23 May 2014 23:22:44 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id u56so5546190wes.28 for ; Fri, 23 May 2014 16:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=xvjwsAL2TIgDrTrpyDHu9cWUObxjU1cbqv4ivaMZWYs=; b=SlJAD4MPOXfPzZ6trp227JB2rnpXO5EXk1xDFYCL1+CyXr9gFZ526s0Dd01BuyZuoO RhD1dL/3NDhv8F/p1IoUTByU7goSgQDz6hrpl3eM+rLXJVzvKcariFS3ngzp2yJ9dve4 ye9HbtnaBCPShXeteBqZuK0cDcQ9GSAr2/RB55bDFMLlszRimsTnGKOGOpFHO+X8e+dT iIVoMy6tYFLVF8A42WeCI1Cz8FrkOQXK9E2RPZ3ckAJp8RPHiJ5AJg2M5yGYZC0b7Mx8 +0L+OHs4QX0GYTPeZMrMyMX62Ro9z388TRF3O0LPXaV6NA6bMS5pTPhxrA4ToEjVsHEH KPWQ== X-Received: by 10.194.120.68 with SMTP id la4mr7435501wjb.40.1400887362834; Fri, 23 May 2014 16:22:42 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id g10sm6040053wjs.33.2014.05.23.16.22.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 May 2014 16:22:41 -0700 (PDT) Sender: Baptiste Daroussin Date: Sat, 24 May 2014 01:22:39 +0200 From: Baptiste Daroussin To: Nathan Whitehorn Subject: Re: svn commit: r266553 - head/release/scripts Message-ID: <20140523232239.GA9268@ivaldir.etoilebsd.net> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <537FD679.6020503@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bryan Drewery 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:45 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 wrot= e: > >>>>>>>>>> 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. > >>>>>>>>>>> > >>>>>>>>>>> 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. > >>>>>>>>>>> > >>>>>>>>>>> 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 delibera= te > >>>>>> decision of the ARM group, since it was meant to be a clean=20 > >>>>>> switchover. > >>>>>> > >>>>>>>>> - The different float abi (even if only one is supported for=20 > >>>>>>>>> now others are > >>>>>>>>> being worked on) > >>>>>>>> armv6 and armv6hf > >>>>>>>> > >>>>>>>>> - 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. > >>>>>> > >>>>>>>> These all already exist. > >>>>>>>> > >>>>>>>>> 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:* > >>>>>>>>> > >>>>>>> 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. > >>>>>> > >>>>>>>> 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. > >>>>>>>> > >>>>>>>> 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. > >>>> > >>>>>>> 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 > >>> > >> > >> 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. > >> > > > > 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. > >> > >> 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. From this > >> discussion, there don't seem to be any actually existing reasons why > >> MACHINE_ARCH doesn't work for this. > > > > 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" We are not insistant just we needed something that work and at the time una= me -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 no= t as easy as it sounds as exposed in that thread I ll for sure integrate the patch if you manage to get it Bapt --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlN/2D8ACgkQ8kTtMUmk6Ex97QCcDJSDrhSuVx/1sOeTOzziPOPq p+MAoJ3QzTBU6mnHkVhQStU0DIM/LXZ4 =43pA -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK--