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 <kilobyte@angband.pl> 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.
Reply to: