Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You can do this without fatelf. Put everything you have into a single package and add "shell scripts and flakey logic to pick the right binary and libraries to load". (He fails to mention, that fatelf is nothing more than this, only hardwired into kernel.)


How are shell scripts and flakey logic an improvement on Apple's cross-platform development/usage model?

  gcc -arch i386 -arch ppc -arch x86_64 -isysroot <SDK path> example.c -o example
Done.

  > file example
  example: Mach-O universal binary with 3 architectures
  example (for architecture i386):	Mach-O executable i386
  example (for architecture ppc7400):	Mach-O executable ppc
  example (for architecture x86_64):	Mach-O 64-bit executable x86_64
I can even transparently run PPC binaries on my x86 Mac.

Universal binaries are a core component of this easy-to-use (for developers and users alike) architecture independence.


What you are demonstrating is the userland toolchain. What was suggested above is an improvement by not requiring meddling with the kernel. Nothing prevents a userland toolchain for Linux from supporting what you are describing above without kernel modifications.


What you are demonstrating is the userland toolchain.

No, what I'm demonstrating is an end-to-end architecture-transparent platform, which includes a complete userspace toolchain, a universal binary format, and necessary kernel and dynamic linker support.

What was suggested above is an improvement by not requiring meddling with the kernel

I'm not sure I understand how "meddling" in the kernel is a bad thing when it provides for user-transparent execution of multi-architecture binaries, including transparent emulation of binaries that lack support for the host architecture.

It's not as if it's complex or dangerous to parse the Mach-O or FatELF formats, and if you take a page from Mac OS X or qemu, you can even do transparent emulation in userspace.

Nothing prevents a userland toolchain for Linux from supporting what you are describing above without kernel modifications.

How is it useful to build an easy-to-use multi-architecture binary if the kernel can't actually execute it?

Why are you afraid of doing simple parsing[1] of the binary? The kernel already does this -- how do you think ELF loading and shell script execution works?

I can imagine this conversation 30 years ago[2] -- "Why should we add shell script shebang parsing/execution support to the kernel? Why not just glue together loader executables that load the shell script"

[1] The dead simple Mach-O universal binary loading code: http://fxr.watson.org/fxr/source/bsd/kern/kern_exec.c?v=xnu-...

[2] The introduction of shebang in UNIX: http://www.in-ulm.de/~mascheck/various/shebang/sys1.c.html


It shouldn't be hard to make an binfmt_misc handler that would rip the correct elf from the fatelf thing (or rather a simple tar) and feed it to kernel, so you can just type ./fatelf-something. You can also make it a shell script with the binary in it, that will choose the correct one and execute it. Both these solutions works without a single kernel line (really), and I can't see anything that fatelf has and these doesn't.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: