Anyone here I can ask a binfmt related question? I have an idea I’d like to implement but one of the foundational tools under it is currently x86-64 only and I don’t know enough to be able to assess if it’s viable to port it to aarch64 (where I live) or other architectures. I’ve never really worked at the generated-assembler level so maybe it’s trivial, maybe it’s out of my reach.
3
Replies
1
Boost
Specifically: the demo code for fzakaria's recent "SQLlite as executable" post making the rounds provided this binfmt loader code, and compiling it on my Aarch64 machine breaks here:
... which is understandable, it says x86-64 on the tin. I'd understood the ELF _format_ to be generic across architectures even if the binary isn't so I'm wondering if making work correctly on non-x86-64 architectures is an easy couple of lines for people who know this layer, or...
The reason I'm interested in this is the idea I meantioned yesterday, about generalizing Carmack's "if it's mostly functional try to make it all the way functional" to "if it's almost [a thing] make it all the way [the thing] and the known benefits of [thing] suddenly appear for free.
The ELF format is almost a database. Know what else is almost a database? Debs. RPMs.
And if an SQLite file is an executable, then DEB control files or RPM package labels are just a tiny table you add later.
"The executable is a database" gives us a bunch of things that I think are interesting. Install/remove becomes download/delete and a symlink. The tools we use to interrogate binaries stop being fiddly parsers and start being declarative, structured queries. You can easily extend the database to accomodate new package managers, so unified installers stop being elaborate shell contraptions and start being less than 1kb in a new table. And you can put anything else you want in there too.
