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. _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"