Adding a MACHINE_ARCH note

[Warner Losh]

On Jul 10, 2013, at 1:55 PM, Baptiste Daroussin wrote:

> On Wed, Jul 10, 2013 at 12:26:42PM -0700, Adrian Chadd wrote:
>> On 10 July 2013 09:55, Warner Losh <imp at bsdimp.com> wrote:
>> 
>>>> That's the reason I replied about it. Not specifically to make it
>>>> happen _everywhere_, but to see if we're about to migrate to a tool
>>>> that doesn't support it, making it a much bigger deal to migrate again
>>>> later.
>>> 
>>> I've been talking to Baptiste, and it will support this.
>> 
>> Sweet.
>> 
>> Thanks!
>> 
>> 
>> -adrian
> 
> Yeah I need to get a simple and uniq way to gather the different ABI, I have
> been creating my own ABI string to solve this, but I'm far from being a
> specialist.

uname -p

> While thinking about this kind of thing, please please think about a format that
> can easily give us a way to figure out a way to get cross ABI binaries support.

The same way we've always handled it: uname -p

> pkgng needs for example to allow i386 packages to be installed on amd64 because
> amd64 does support it.

You'll need to maintain a list somewhere.

> Maintaining a list the compatibility will be painful.
> 
> In my own version I have
> os:version:family:class:...
> 
> for example here:
> on FreeBSD 9 i386 we have:
> 
> freebsd:9:x86:32
> 
> on FreeBSD 10 amd64 we have:
> 
> freebsd:9:x86:64
> 
> now if I do want a package I can install on both amd64 and i386 I just have to
> create a package saying:
> 
> freebsd:9:x86
> 
> or if I want a package that can be installed on all arches:
> 
> freebsd:9

The whole x86:64 thing is evil. It should just be uname -p's name.

> It became complicated for arm and mips because of the multiple variation
> available.

Except there uname -p uniquely defines it (apart from our transition in current from OABI to EABI on ARM, which was justified as "weird things happen in -current" :)).

> the problem with that is that I have to read the binary supported from the
> binaries themselves which enforce me to get some magical numbers for every
> arches (which was apparently wrong on arm, thanks Andrew for the fix) Having a
> note with the direct MACHINE_ARCH will save us complicated code and potential
> failures with magic numbers. and would be more reliable that getting from
> uname(3).

I'm not sure how it would be more reliable. MACHINE_ARCH is uname -p.

> Just tell me where I can get the right string and how can I check the compatible
> ABI and pkgng will switch to it. I would have love this to happen a year and a
> half before that would have saved me from having to prepare a migration path,
> but better late that never :)

uname -p is the first cut. It is intended to completely describe the main ABI of the current machine.

However, you're right. The kernel should export a list of ABIs that it supports. We don't currently do that.

I'd propose hw.abi that will export the ABIs the kernel supports. This way you won't install i386 binaries on an AMD64 system that doesn't have COMPAT_FREEBSD32 in it. But that might get more interesting, since there are some ABIs we support that aren't uname -p. These are things like SVR4, AOUT (on i386), and various flavors of Linux. These ABIs are likely beyond the scope of pngng, but maybe linux isn't :)

Anyway, I'll work up a patch to give you what you need, and some shell code for what to do when it doesn't exist.

Warner