Date: Fri, 23 May 2014 16:34:06 -0500 From: Bryan Drewery <bdrewery@FreeBSD.org> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: svn-src-head@freebsd.org, Baptiste Daroussin <bapt@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r266553 - head/release/scripts Message-ID: <8740c21d1e7467ea0e0355c5d05729c9@shatow.net> In-Reply-To: <537FBB4E.2010409@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. > 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? > -Nathan -- Regards, Bryan Drewery
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8740c21d1e7467ea0e0355c5d05729c9>