Re: Multiarch interpreter names for traditional architectures

[Javier Serrano Polo <javier at jasp dot net>]

El dl 05 de 02 de 2018 a les 07:01 +0100, Florian Weimer va escriure:
> Please rephrase that in a way which separates what happens today from 
> what should happen in the future.

We are still in the alpha on x86 example. What happens today on your
systems:

     1. Kernel starts the alpha emulator.
     2. The emulator looks for /lib/ld-linux.so.2.
     3. The program fails.

What happens today on my systems:

     1. Kernel starts the alpha emulator.
     2. The emulator looks for /lib/ld-linux.so.2.
     3. User has configured the emulator to redirect all file operations
        to /lib/ld-linux-alpha.so.2.
     4. The program runs, but the path /lib/ld-linux.so.2 will not work
        as expected.

What should happen in the future:

     1. Kernel starts the alpha emulator.
     2. The emulator looks for /lib/ld-linux.so.2.
     3. User has configured the emulator to use /lib/ld-linux-alpha.so.2
        as the interpreter, even if /lib/ld-linux.so.2 exists.
     4. The program runs.

What happens with multiarch binaries:

     1. Kernel starts the alpha emulator.
     2. The emulator looks for /lib/ld-linux-alpha.so.2.
     3. The program runs.

> Currently, the kernel maps both the ELF interpreter and the executable. 
> Do you intend to change that?

The only ability I add to the kernel is to map an alternative
interpreter if the requested one is not found.

But we are deviating from the topic: what should the multiarch
interpreter names be? I like Zack's view. It does not follow the current
practice of using infixes, but multiarch filesystems become cleaner and
interpreter names are unique easily.

Attachment: smime.p7s
Description: S/MIME cryptographic signature