svn commit: r266553 - head/release/scripts

Warner Losh imp at bsdimp.com
Sat May 24 18:56:30 UTC 2014


On May 24, 2014, at 8:59 AM, Tijl Coosemans <tijl at FreeBSD.org> wrote:

> On Fri, 23 May 2014 17:29:48 -0600 Warner Losh wrote:
>> On May 23, 2014, at 10:20 AM, Baptiste Daroussin <bapt at 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.

ABIs like x32 would not have a MACHINE_ARCH of “amd64” but would have
a MACHINE_ARCH of “x32”. This is exactly what we do with mips today. So
this ins’t an argument for not using MACHINE_ARCH directly, rather than having
an arbitrary mapping (which is the problem with the proposed scheme).

MACHINE_ARCH, as it stands in FreeBSD, uniquely defines the ABI (modulo
occasional bugs that are fixed).

> The advantage of the pkg scheme is that it has a formal structure.  That's
> what makes it flexible, extensible, machine parsable, etc.  I'd rather see
> the rest of FreeBSD adopt this scheme than that pkg would have to adopt
> the informal names.  The use of x86 instead of i386/amd64 is part of the
> idea to merge more of sys/i386 and sys/amd64 into sys/x86 and eventually
> define MACHINE as "x86”.

MACHINE and MACHINE_ARCH are different. Please don’t confuse them.

> Patterns like freebsd:9:* will probably become more prevalent when support
> for subpackages is added.  Some of the subpackages (like documentation) will
> be ABI independent.

True, but not relevant to the machine name you use.

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20140524/7f986f18/attachment.sig>


More information about the svn-src-head mailing list