Date: Wed, 10 Jul 2013 15:27:12 -0600 From: Warner Losh <imp@bsdimp.com> To: Baptiste Daroussin <bapt@freebsd.org> Cc: Adrian Chadd <adrian@freebsd.org>, Dimitry Andric <dim@freebsd.org>, Andrew Turner <andrew@fubar.geek.nz>, freebsd-arch@freebsd.org Subject: Re: Adding a MACHINE_ARCH note Message-ID: <AE10F27F-6D86-45F0-8C8D-1274CF09CC42@bsdimp.com> In-Reply-To: <20130710212436.GF68830@ithaqua.etoilebsd.net> References: <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <CAJ-Vmo=sUKs4u-pq%2B1hx-q1bfhPugMcSp4XYzNcBNwHMrw3Kug@mail.gmail.com> <20130710195547.GB68830@ithaqua.etoilebsd.net> <201307101611.37437.jhb@freebsd.org> <20130710212436.GF68830@ithaqua.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 10, 2013, at 3:24 PM, Baptiste Daroussin wrote: > On Wed, Jul 10, 2013 at 04:11:37PM -0400, John Baldwin wrote: >> On Wednesday, July 10, 2013 3:55:47 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. >>>=20 >>> 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. >>>=20 >>> pkgng needs for example to allow i386 packages to be installed on = amd64 because >>> amd64 does support it. >>>=20 >>> 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 >>>=20 >>> It became complicated for arm and mips because of the multiple = variation >>> available. >>=20 >> You should look at how MACHINE_CPUARCH vs MACHINE vs MACHINE_ARCH = works. >>=20 >> Keep in mind that amd64/i386/pc98 should probably have = MACHINE_CPUARCH of x86, >> but we just haven't done that yet. If we did that I think you could = follow >> src's conventions and be fine. Something like: >>=20 >> os:version:cpuarch:arch >>=20 >> Where cpuarch =3D=3D MACHINE_CPUARCH (should be x86 on = amd64/i386/pc98, but isn't >> yet. It ss sane on other platforms) and >> arch =3D=3D MACHINE_ARCH (amd64/i386 (for pc98 MACHINE_ARCH is i386)) >>=20 >> So that would give: >>=20 >> freebsd:9:x86:amd64 >> freebsd:9:x86:i386 (for both pc98 and i386) >> freebsd:9:arm:armv6 >>=20 >> etc. >>=20 >> I think that means we could eventually support x32 as: >>=20 >> freebsd:9:x86:x32 >>=20 >> We might have an x32 world (but perhaps not a kernel?, though we = would need >> the headers to DTRT) >=20 > I do like the idea a lot. We should add a flag to uname to get MACHINE_CPUARCH, and publish it as = hw.cpu_arch in sysctl. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AE10F27F-6D86-45F0-8C8D-1274CF09CC42>