让我至少回答你问题的一部分。通过一个例子说明Linux ABI如何影响系统调用，以及它为什么有用。

A systemcall is a way for a userspace program to ask the kernelspace for something. It works by putting the numeric code for the call and the argument in a certain register and triggering an interrupt. Than a switch occurs to kernelspace and the kernel looks up the numeric code and the argument, handles the request, puts the result back into a register and triggers a switch back to userspace. This is needed for example when the application wants to allocate memory or open a file (syscalls "brk" and "open").

现在系统调用有简短的名称“brk”等和相应的操作码，这些在系统特定的头文件中定义。只要这些操作码保持不变，您就可以使用不同更新的内核运行相同的已编译用户域程序，而无需重新编译。这样就有了预编译二进制文件使用的接口，因此就有了ABI。

应用程序二进制接口(ABI)

功能:

从程序员的模型到底层系统的域数据的转换 类型，大小，对齐，调用约定，它控制如何 函数的参数被传递并返回检索到的值;的 系统调用编号以及应用程序应该如何进行系统调用 到操作系统;高级语言编译器的名称 破坏方案、异常传播和调用约定 在同一平台上的编译器之间，但不需要 跨平台兼容性……

现有的实体:

直接参与程序执行的逻辑块:ALU， 通用寄存器，用于内存/ I/O映射的寄存器，等等…

消费者:

语言处理器，链接器，汇编器…

任何必须确保构建工具链作为一个整体工作的人都需要这些。如果你用汇编语言写一个模块，用Python写另一个模块，而不是你自己的引导加载程序想要使用操作系统，那么你的“应用程序”模块是跨“二进制”边界工作的，需要这种“接口”的协议。

c++命名混乱，因为应用程序中可能需要链接来自不同高级语言的目标文件。考虑使用GCC标准库对Visual c++构建的Windows进行系统调用。

ELF是用于解释的来自对象文件的链接器的一种可能期望，尽管JVM可能有其他想法。

对于一个Windows RT商店应用程序，如果你真的想让一些构建工具链一起工作，尝试搜索ARM ABI。

为了调用共享库中的代码，或者在编译单元之间调用代码，object文件需要包含调用的标签。c++修改了方法标签的名称，以加强数据隐藏并允许重载方法。这就是为什么您不能混合来自不同c++编译器的文件，除非它们显式地支持相同的ABI。

如果您了解汇编以及操作系统级别的工作方式，那么您就符合特定的ABI。ABI控制参数的传递方式、返回值放置的位置等。对于许多平台来说，只有一种ABI可供选择，在这些情况下，ABI只是“事情如何工作”。

然而，ABI也控制着c++中类/对象的布局。如果您希望能够跨模块边界传递对象引用，或者如果您希望混合使用不同编译器编译的代码，这是必要的。

此外，如果您有一个可以执行32位二进制文件的64位操作系统，那么32位和64位代码将有不同的abi。

通常，链接到相同可执行文件中的任何代码都必须符合相同的ABI。如果希望在使用不同abi的代码之间进行通信，则必须使用某种形式的RPC或序列化协议。

我认为你过于努力地将不同类型的界面挤进一个固定的特征集。例如，一个界面不一定要分成消费者和生产者。接口只是两个实体交互的约定。

abi可以(部分地)与isa无关。有些方面(如调用约定)依赖于ISA，而其他方面(如c++类布局)则不依赖于ISA。

定义良好的ABI对于编写编译器的人来说非常重要。如果没有定义良好的ABI，就不可能生成可互操作的代码。

编辑:需要澄清的一些注释:

ABI中的“二进制”并不排除字符串或文本的使用。如果您想要链接一个导出c++类的DLL，则必须对其中的方法和类型签名进行编码。这就是c++名称破坏的用武之地。 您从未提供ABI的原因是绝大多数程序员都不会这样做。ABI是由设计平台(即操作系统)的人提供的，很少有程序员有特权设计一个广泛使用的ABI。

让我至少回答你问题的一部分。通过一个例子说明Linux ABI如何影响系统调用，以及它为什么有用。

A systemcall is a way for a userspace program to ask the kernelspace for something. It works by putting the numeric code for the call and the argument in a certain register and triggering an interrupt. Than a switch occurs to kernelspace and the kernel looks up the numeric code and the argument, handles the request, puts the result back into a register and triggers a switch back to userspace. This is needed for example when the application wants to allocate memory or open a file (syscalls "brk" and "open").

现在系统调用有简短的名称“brk”等和相应的操作码，这些在系统特定的头文件中定义。只要这些操作码保持不变，您就可以使用不同更新的内核运行相同的已编译用户域程序，而无需重新编译。这样就有了预编译二进制文件使用的接口，因此就有了ABI。

我也试图理解ABI, JesperE的回答很有帮助。

从一个非常简单的角度来看，我们可以尝试通过考虑二进制兼容性来理解ABI。

KDE wiki将库定义为二进制兼容的，“如果动态链接到库的前版本的程序继续与库的新版本一起运行，而不需要重新编译”。有关动态链接的更多信息，请参阅静态链接与动态链接

现在，让我们试着看看一个库需要二进制兼容性的最基本方面(假设库没有源代码更改):

相同/向后兼容的指令集架构(处理器指令、寄存器文件结构、堆栈组织、内存访问类型，以及处理器可以直接访问的基本数据类型的大小、布局和对齐) 相同调用约定 同名混淆约定(如果Fortran程序需要调用一些c++库函数，这可能是需要的)。

当然，还有许多其他细节，但这主要是ABI所涵盖的内容。

更具体地回答你的问题，由以上，我们可以推断:

ABI功能:二进制兼容性 现有实体:现有程序/库/操作系统 消费者:库，操作系统

希望这能有所帮助!