Bug#819207: ITP: arch-detect -- detect architectures supported by your machine/kernel
On Fri, Mar 25, 2016 at 12:40:12AM -0400, Mathieu Trudel-Lapierre wrote: > On Thu, Mar 24, 2016 at 6:50 PM, Adam Borowski wrote: > > * Package name: arch-detect > > * URL : https://github.com/kilobyte/arch-detect > > Description : detect architectures supported by your machine/kernel > > > > > It seems like the naming would clash with archdetect (from hw-detect, built > with some libdebian-installer magic). > > That package is currently just a udeb, but it *does* make sense as a > standard package, there might simply be a need to do some renaming. Thanks for noticing the conflict, I did not look for udebs. > I'm not saying it's a bad name, just that there already exists an > archdetect, and having just a - as a difference may be confusing. It may be > worth combining the two "projects" if possible. I know archdetect should > work on kfreebsd-*. It turns out these two are unrelated: DI's archdetect detects a "subarch" of a given architecture, which answers the question "What kernel would be best for this machine? What doodads like EFI does the machine have?". My arch-detect detects architectures in dpkg's sense that the already running kernel can run (possibly with the help of binfmts/etc). > > This package lets you enumerate architectures that your kernel can run. > > The check is for the ability to run machine code and supporting > > appropriate > > syscall ABI -- you may need to install userland libraries in a chroot, > > container or via multiarch to actually execute non-static binaries of such > > architectures. > > What would the expected output be on a typical amd64 system? Does it > differentiate between EFI and non-EFI? Typical amd64: amd64 i386. With syscall.x32=y also x32. It doesn't deal with hardware drivers like EFI/non-EFI at all. archdetects looks at hardware, my arch-detect at kernel's configuration. On an ARMv7 machine, archdetect might say "armmp" or "omap", arch-detect will list "armel armhf" and, if CONFIG_OABI_COMPAT is set, "arm". Ie, archdetect is useful when installing a new system, arch-detect when you debootstrap a chroot or dpkg --add-architecture. With this in mind, what kind of a name would avoid stepping on DI team's toes? Save for qemu-likes, the main use of my tool is about kernel<->userland ABI. I'd keep the word "arch" somehow, as it's hard to describe it otherwise in a concise way: "kernel ABI" would suggest loadable module compat, userland ABI has many other meanings as well. I have trouble coming up with a new name, could you suggest something? Meow! -- A tit a day keeps the vet away.
Bug#819207: ITP: arch-detect -- detect architectures supported by your machine/kernel
On Thu, Mar 24, 2016 at 6:50 PM, Adam Borowski wrote: > Package: wnpp > Severity: wishlist > Owner: Adam Borowski > > * Package name: arch-detect > Upstream Author : me > * URL : https://github.com/kilobyte/arch-detect > * License : MIT > Programming Lang: mostly assembler > Description : detect architectures supported by your machine/kernel > > It seems like the naming would clash with archdetect (from hw-detect, built with some libdebian-installer magic). That package is currently just a udeb, but it *does* make sense as a standard package, there might simply be a need to do some renaming. I'm not saying it's a bad name, just that there already exists an archdetect, and having just a - as a difference may be confusing. It may be worth combining the two "projects" if possible. I know archdetect should work on kfreebsd-*. > This package lets you enumerate architectures that your kernel can run. > The check is for the ability to run machine code and supporting > appropriate > syscall ABI -- you may need to install userland libraries in a chroot, > container or via multiarch to actually execute non-static binaries of such > architectures. > What would the expected output be on a typical amd64 system? Does it differentiate between EFI and non-EFI? / Matt
Bug#819207: ITP: arch-detect -- detect architectures supported by your machine/kernel
Package: wnpp Severity: wishlist Owner: Adam Borowski * Package name: arch-detect Upstream Author : me * URL : https://github.com/kilobyte/arch-detect * License : MIT Programming Lang: mostly assembler Description : detect architectures supported by your machine/kernel This package lets you enumerate architectures that your kernel can run. The check is for the ability to run machine code and supporting appropriate syscall ABI -- you may need to install userland libraries in a chroot, container or via multiarch to actually execute non-static binaries of such architectures. . Architectures detected by this version of arch-detect are: * amd64, i386, x32 * mips, mipsel, mips64, mips64el * arm, armel, armhf, arm64 * powerpc, ppc64, ppc64el * m68k * sh4 * s390x * sparc64 * illumos-amd64 * win32, win64 My reason here is that x32 can't be detected other than trying a syscall and seeing if it fails. But then, we don't want a 344 byte package -- so here's one that handles all release archs and most -ports ones. Most of these can be detected by reading /proc and binfmts, but that's neither easy nor reliable -- testing empirically works better. Some quirks: * ppc64el: I check "mtvsrd r0, r0" to fail qemu if it suffers from #813698 * armhf: "dmb" nicely SIGILLs on RPi 1, are there other ARMv7-but-not-armhf in the wild worth checking? * arm: untested (does anyone have that old hardware?) -- fails on all porterboxes but succeeds on both kernel 3.8 on Odroid-U2 and 4.1 on Raspbian RPI 1. Archs that are missing: * kfreebsd-*: no cross binutils in unstable (uses a different format, unlike hurd and Solaris which share it with Linux) * hurd: how do you even do syscalls there?!? Trying to figure it out exhausted my attention span. RTFSing glibc, I see it's something bizarre: _exit() requests some server to terminate the process then goes into an endless loop of dividing 1/0. * alpha: no machine to test it on, I'm reluctant to trust qemu exclusively * hppa: no machine to test, not even supported by qemu * ia64: no cross binutils * sparc: binutils can multilib it, does anyone still want it? * powerpcspe: no machine, debootstrap in qemu fails Naming issues: * illumos-amd64: (Solaris): dpkg's table has different names; I used this one as it's an established unofficial port in a pretty good shape; you may argue a different name though -- like, something that mentions that this syscall ABI works on real Solaris... * win32, win64: should I name them -i386, -amd64? Not sure if detecting them even makes sense -- binfmts exist but you're not going to chroot/ multiarch those...
