On May 24, 2014, at 5:13 PM, Tijl Coosemans <t...@freebsd.org> wrote:
> On Sat, 24 May 2014 11:57:44 -0700 Nathan Whitehorn wrote: >> On 05/24/14 11:23, Ian Lepore wrote: >>> On Sat, 2014-05-24 at 18:53 +0200, Tijl Coosemans wrote: >>>> On Sat, 24 May 2014 09:04:33 -0700 Nathan Whitehorn wrote: >>>>> On 05/24/14 07:59, Tijl Coosemans wrote: >>>>>> On Fri, 23 May 2014 17:29:48 -0600 Warner Losh wrote: >>>>>>> On May 23, 2014, at 10:20 AM, Baptiste Daroussin <b...@freebsd.org> >>>>>>> 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. >>>>> No, it wouldn't. MACHINE_ARCH would be something else (x32, probably) in >>>>> such cases. MACHINE_ARCH (and uname -p, which reports it) is the FreeBSD >>>>> ABI identifier and encodes 100% of the ABI information. This would be >>>>> true even if there is never an x32 kernel. >>>> No, there's no such thing as an x32 kernel. It's an amd64 kernel that >>>> supports a second userland ABI. In C preprocessor terms they are >>>> distinguished by (__amd64__ && _LP64) and (__amd64__ && !_LP64). >>>> uname -p gives you the processor architecture (the __amd64__ bit) but >>>> then you can still choose the sizes of standard C types (the _LP64 bit). >>>> So far we've always had one ABI per processor architecture but this >>>> is not strictly necessary. >>> >>> All you have to do is look at the plethora of ARM ABIs we support (and >>> the corresponding separate kernel for each) to see the falseness of that >>> last sentence. ARM variations include v4 vs v6, OABI vs EABI (calling >>> and register usage standards), hard vs soft float, little vs big endian. >>> Virtually all combinations of those are possible (there are a few combos >>> we don't support), and each one has its own MACHINE_ARCH. >> >> Exactly. This doesn't rely on the kernel either. The hw.machine_arch >> sysctl (what uname -p returns) gives the ABI of the calling binary >> rather than the kernel. So if you use a 32-bit uname (e.g. in a chroot) >> on an amd64 host, you get i386. The same will be true if and when we >> support a 32-bit amd64 userland -- even if there is no x32 kernel, an >> x32 uname will return "x32" (or "amd32" or whatever it ends up being >> called). That string will also appear in kern.supported_archs. > > There isn't necessarily any chroot environment. There's one kernel, > two equally valid ABIs (ILP32 and LP64) and any binary like uname might > use either of them. If uname -p returns a different result depending on > which of these two ABIs it was compiled for that could be a problem for > any script that uses it. Well, it depends on what you want to do with the script, eh? If you want to know the ABI of the native binary uname, that’s one thing. But if you want to know the supported ABIs, you are doing it wrong by using uname. You should be using sysctl kern.supported_abi. That will tell you all the ABIs that you can install packages for on this machine, which is what you really want to know. So I’m having trouble connecting the dots between this and what you are saying here. I still am absolutely flabbergasted why the MACHINE_ARCH names aren’t necessary and sufficient for packaging. I’ve yet to see any coherent reason to not use them. Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
