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.
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".
We need one set of platform names. FreeBSD has used MACHINE_ARCH values
for a very long time for this and uses them absolutely everywhere in the
ports and src trees -- except for the internals of pkg. I don't think
they can be changed at this point, even if some names are slightly
cryptic. They are at least internally consistent, and that's a huge win.
I agree it will be good to get i386 and amd64 sharing a MACHINE_CPUARCH
and MACHINE value at some point, but it's not really related to the
issue of uniform ABI tags.
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.
That wouldn't be affected by using standard ABI identifiers.
On a more general note, any flexibility provided by things like x86:64
is illusory anyway. Not all amd64 systems can run i386 binaries. Some
ia64 systems *can* run i386 binaries. i386 systems cannot run amd64
binaries on FreeBSD -- but on OS X they sometimes can. Some powerpc
systems can run little-endian binaries, but not all (G5s notably
cannot). It's just not possible to make static decisions here and there
doesn't seem to be any reason to invent a fragile alternative definition
of ABI identifiers that is at variance with everything else in FreeBSD
for apparently the sole purpose of facilitating something that is
intrinsically fragile and can't be relied upon. This is especially true
given that the kernel *does* tell you, in MACHINE_ARCH terms, what
binaries any given system can run -- but for pkg to use that
information, it currently needs a mapping table!
-Nathan
_______________________________________________
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"
