Naming convention for plugins using GNU_PROPERTY_X86_ISA_1_NEEDED

Naming convention for plugins using GNU_PROPERTY_X86_ISA_1_NEEDED

[Thiago Macieira via Libc-alpha]

Hello

Now that glibc/libdl has support for determining that an ELF module can or 
cannot be loaded into memory absed on the GNU_PROPERTY_X86_ISA_1_NEEDED 
property in NT_GNU_PROPERTY_TYPE_0, I'd like to know if the community has a 
suggestion to how plugin frameworks should name their plugins. This is a 
separate but related discussion to how to load them.

For a few years now, Clear Linux has already been doing this: we build code 
multiple times and store multiple versions of it. For binaries, we used (to 
use) a subdir of /usr/bin; for libraries, the glibc-hwcaps that existed at the 
time was enough. For plugins, we needed to come up with a naming convention so 
multiple files could be stored.

Our choice was to append ".avx2" to builds with -march=haswell (x86-64-v3) and 
".avx512" for builds with -march=skyalke-avx512 (x86-64-v4). For example:

$ ls -1 /usr/lib/python3.9/site-packages/zstd.*
/usr/lib/python3.9/site-packages/zstd.cpython-39-x86_64-linux-gnu.so
/usr/lib/python3.9/site-packages/zstd.cpython-39-x86_64-linux-gnu.so.avx2
/usr/lib/python3.9/site-packages/zstd.cpython-39-x86_64-linux-gnu.so.avx512

So the questions to the community are:

1) do we want to suggest a standard way for plugin frameworks to name their 
plugins?

2) do we have a preference on how to name them? Possibilities I can think of:

a) append .avx2 / .avx512, like Clear has been doing for years
(note: Clear's baseline is x86-64-v2, so we haven't needed an earlier moniker)

b) append .x86-64-vX

c) append just ".vX" since plugins are already in their right arch-specific 
dir anyway

d) append to the path but leave the file name intact

e) infix something before the ".so", such as "pluginname.v3.so"


(a) through (c) are simplest to develop, both in creating such plugins and in 
modifying the plugin-loading frameworks. A disadvantage is that the plugin 
file name will not match the DT_SONAME, if the plugin got one. (a) keeps 
compatibility with Clear Linux, (b) is more verbose than (c) but (c)'s name 
may be confusing with a plugin's own version instead of the ISA version.

(d) keeps the DT_SONAME and file names matching, plus also reduces the number 
of files in the directory (not that I think this is an issue). This is pretty 
easy to implement in the plugin buildsystems too, but requires a bit more 
effort to implement in the plugin-loading mechanisms. A disadvantage is that 
the plugin will be at a subdirectory of where it was expected to be and this 
may break plugins that attempt to find anything relative to themselves 
($ORIGIN included).

I don't recommend (e). It allows for globbing *.so to find the plugins, but it 
makes path manipulation much more complex for both the buildsystems and the 
plugin frameworks.

Any recommendations?


Please note this naming convention may become used in non-glibc OSes too, 
especially the BSDs and MUSL-based Linux and potentially Android. I doubt 
macOS will want this (they have fat binaries and there's a sub-arch for 
x86-64-v3).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering