Date: Wed, 10 Jul 2013 22:25:39 -0600 From: Warner Losh <imp@bsdimp.com> To: Tim Kientzle <tim@kientzle.com> Cc: Baptiste Daroussin <bapt@freebsd.org>, FreeBSD-arch Arch <freebsd-arch@freebsd.org> Subject: Re: Adding a MACHINE_ARCH note Message-ID: <D8EE685E-098D-44E0-AB52-2C2D31946225@bsdimp.com> In-Reply-To: <F1E520E9-F092-40D3-B830-22E8740FE217@kientzle.com> 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> <2CFD4681-5299-4A7B-A099-758EF30DAB9A@bsdimp.com> <F1E520E9-F092-40D3-B830-22E8740FE217@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 10, 2013, at 10:03 PM, Tim Kientzle wrote: > On Jul 10, 2013, at 1:27 PM, Warner Losh wrote: >=20 >> On Jul 10, 2013, at 1:55 PM, Baptiste Daroussin wrote: >>=20 >>> 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 :) >>=20 >> uname -p is the first cut. It is intended to completely describe the = main ABI of the current machine. >>=20 >> However, you're right. The kernel should export a list of ABIs that = it supports. We don't currently do that. >>=20 >> I'd propose hw.abi that will export the ABIs the kernel supports.=20 >=20 > How does this work in the case where I'm building an armv6 image > on an i386 system? Or doing package installs directly on my NFS > server, which isn't the same architecture as the diskless systems > running from it? For that matter, just querying the kernel would > give wrong results for an i386 jail running on amd64, where the > kernel might support amd64 but 64-bit libraries aren't available. Sounds like a good number of cases for an override flag. > In all of these cases, it's the ABI of the target system that matters, > and there's no running kernel to query. Usually you have a kernel to query. When you don't, the user will have = to tell the pkg tools what to use. > This is why pkgng today looks at ELF information in /bin/sh to > determine what is supported by the target system. But that's still not right, since it will only allow you to install one = ABI. It would be impossible to install i386 packages on an amd64 = machine, so I'm not sure this is a winning argument. > How can we code information equivalent to uname -p in > a place where it can be statically determined from an image > of a non-running system? I would wager that most of the time, uname -p is what you want. Since = you are trying to second guess what's going on, while still allowing for = a wider variety of things, we'd need to have some automatic way of = determining what's supported, but also some way to override it. Most of the time, pkgng is used by a user installing packages on the = system he or she will be running on. We should optimize that path, while = still allowing others to work with an override flag. Much like we = default to the current running system in buildworld, unless you = override, and we don' t allow you to install on a system where = TARGET_ARCH !=3D MACHINE_ARCH unless you specify an override. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D8EE685E-098D-44E0-AB52-2C2D31946225>