Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3386 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20180205/ad504b88/attachment.p7s>