Date: Wed, 10 Jul 2013 14:27:30 -0600 From: Warner Losh <imp@bsdimp.com> To: Baptiste Daroussin <bapt@freebsd.org> Cc: FreeBSD-arch Arch <freebsd-arch@freebsd.org> Subject: Re: Adding a MACHINE_ARCH note Message-ID: <2CFD4681-5299-4A7B-A099-758EF30DAB9A@bsdimp.com> In-Reply-To: <20130710195547.GB68830@ithaqua.etoilebsd.net> References: <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> <CAJ-Vmo=iV8BsGriFRgNuP-ZJdQhpmBLhjAkz-nSVRS0HPKSyOQ@mail.gmail.com> <CAGE5yCpJmRDvnaYtozj4bCqNoQXH=1e96HPJAqwJuRdn4H9BZA@mail.gmail.com> <CAJ-Vmo=tmGDW3Ubw9nr5rb30bXr1dcJUkKLOU7L=_bx29zvEhw@mail.gmail.com> <CAGE5yCq9gQERDkbi4wu=6tNUap24ZR7sL7aF%2BzmEO0eT6nxPsA@mail.gmail.com> <F79E2F76-A234-499A-ABB7-1ABA62283E9D@FreeBSD.org> <CAJ-VmonwJJ7AtCTCDXGOW2k9RufCG3Vj0Tqy3DAO_wZb6cYg6Q@mail.gmail.com> <752588A3-C0EF-4844-A0EE-4657CAD40E4C@bsdimp.com> <CAJ-Vmo=sUKs4u-pq%2B1hx-q1bfhPugMcSp4XYzNcBNwHMrw3Kug@mail.gmail.com> <20130710195547.GB68830@ithaqua.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@bsdimp.com> wrote: >>=20 >>>> 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. >>>=20 >>> I've been talking to Baptiste, and it will support this. >>=20 >> Sweet. >>=20 >> Thanks! >>=20 >>=20 >> -adrian >=20 > 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. >=20 > In my own version I have > os:version:family:class:... >=20 > for example here: > on FreeBSD 9 i386 we have: >=20 > freebsd:9:x86:32 >=20 > on FreeBSD 10 amd64 we have: >=20 > freebsd:9:x86:64 >=20 > now if I do want a package I can install on both amd64 and i386 I just = have to > create a package saying: >=20 > freebsd:9:x86 >=20 > or if I want a package that can be installed on all arches: >=20 > 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2CFD4681-5299-4A7B-A099-758EF30DAB9A>