Date: Mon, 26 May 2014 11:35:02 +0200 From: Tijl Coosemans <tijl@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: Baptiste Daroussin <bapt@freebsd.org>, src-committers@freebsd.org, Ian Lepore <ian@freebsd.org>, svn-src-all@freebsd.org, Glen Barber <gjb@freebsd.org>, Nathan Whitehorn <nwhitehorn@freebsd.org>, svn-src-head@freebsd.org Subject: Re: svn commit: r266553 - head/release/scripts Message-ID: <20140526113502.239db74d@kalimero.tijl.coosemans.org> In-Reply-To: <9FE34CE4-C71F-4806-9EF6-30CB1051C62F@bsdimp.com> References: <201405221922.s4MJM4Y9025265@svn.freebsd.org> <537F6706.6070509@freebsd.org> <20140523153619.GF72340@ivaldir.etoilebsd.net> <537F6EBC.3080008@freebsd.org> <20140523162020.GG72340@ivaldir.etoilebsd.net> <C5A59513-AF58-4749-BCD7-F54BB6F56E90@gmail.com> <20140524165940.3c687553@kalimero.tijl.coosemans.org> <5380C311.60201@freebsd.org> <20140524185345.263f230d@kalimero.tijl.coosemans.org> <1400955835.1152.323.camel@revolution.hippie.lan> <5380EBA8.1030200@freebsd.org> <20140525011307.142b41ab@kalimero.tijl.coosemans.org> <3CCAFAD3-FABE-40EF-ABF9-815FE5826349@bsdimp.com> <9FE34CE4-C71F-4806-9EF6-30CB1051C62F@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 24 May 2014 19:00:18 -0600 Warner Losh wrote: > On May 24, 2014, at 5:53 PM, Warner Losh <imp@bsdimp.com> wrote: >> On May 24, 2014, at 5:13 PM, Tijl Coosemans <tijl@freebsd.org> wrote: >>> There isn't necessarily any chroot environment. There's one kernel, >>> two equally valid ABIs (ILP32 and LP64) and any binary like uname might >>> use either of them. If uname -p returns a different result depending on >>> which of these two ABIs it was compiled for that could be a problem for >>> any script that uses it. >>=20 >> Well, it depends on what you want to do with the script, eh? If you want >> to know the ABI of the native binary uname, that=A2s one thing. But if y= ou >> want to know the supported ABIs, you are doing it wrong by using uname. >> You should be using sysctl kern.supported_abi. That will tell you all the >> ABIs that you can install packages for on this machine, which is what you >> really want to know. So I=A2m having trouble connecting the dots between >> this and what you are saying here. >>=20 >> I still am absolutely flabbergasted why the MACHINE_ARCH names aren=A2t >> necessary and sufficient for packaging. I=A2ve yet to see any coherent >> reason to not use them. >=20 > Why do I care that they match? Good question. When I was doing FreeNAS, I > looked at integrating pkgng into nanobsd. At the time this was quite > difficult because every single architecture name was different between > pkgng and MACHINE_ARCH. This would mean I=A2d have to drag around a huge > table to know how to translate one to the other (there was no simple regex > either, and things like mipsn32 wouldn=A2t have fit into the scheme at the > time). I would very much like us to see us keep these names in sync and > avoid large translation tables that are difficult to maintain. >=20 > Now, do you need to get it from uname -p? No. If you want to parse elf > files to get it, that=A2s fine, so long as the names map directly to the > MACHINE_ARCH names that we=A2ve been using for years. They completely > describe the universe of supported platforms. Are they perfect? No, around > the edge there may be an odd-ball that=A2s possible to build, but is > unsupported and likely doesn=A2t work at all. Have we learned from these > mistakes? Yes. Anything that=A2s actively supported has a proper name. Th= is > name is needed, btw, so that any machine can self-host, a nice feature of > the /usr/src system. ABI consists of the following elements: - OS - OS ABI version (major version number in FreeBSD) - instruction set - programming model (ILP32 or LP64) - byte order (little/big endian) These are almost orthogonal dimensions in the sense that almost any combination is possible. (A combination that isn't possible is a 32-bit instruction set with LP64.) What you are asking for now is to combine two dimensions into one and combination in this case means multiplication so if you have 3 instruction sets and 2 programming models, the combined dimension needs 6 different values. You need to make the case for why you think this is a good idea. For the past 20 years we got away with this because on every installation of FreeBSD we only used one programming model at a time. This is still the case for byte order of course. What I'm saying is to keep the option open for installations with multiple programming models, where most binaries could use ILP32 and only the ones that actually need a 64-bit address space use LP64. You query the instruction set using uname and the programming models using getconf. I suppose you could replace the "x86" in the pkg scheme with i386/amd64, but then you'd still be talking about i386:32, amd64:32 and amd64:64 instead of x86:32, x86:x32 and x86:64.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140526113502.239db74d>