que - Diferencia entre API y ABI

abi significado

Question

Soy nuevo en la programación de sistema de Linux y encontré API y ABI mientras leía Programación de sistema Linux .

Definición de API:

Una API define las interfaces mediante las cuales una pieza de software se comunica con otra en el nivel de origen.

Definición de ABI:

Mientras que una API define una interfaz de origen, una ABI define la interfaz binaria de bajo nivel entre dos o más piezas de software en una arquitectura particular. Define cómo una aplicación interactúa consigo misma, cómo una aplicación interactúa con el kernel y cómo una aplicación interactúa con las bibliotecas.

¿Cómo puede un programa comunicarse a nivel de fuente? ¿Qué es un nivel de fuente? ¿Está relacionado con el código fuente de todos modos? ¿O la fuente de la biblioteca se incluye en el programa principal?

La única diferencia que sé es que API es utilizada principalmente por programadores y ABI es utilizada principalmente por el compilador.

Answer 1

API: interfaz del programa de aplicaciones

Este es el conjunto de tipos / variables / funciones públicas que expone de su aplicación / biblioteca.

En C / C ++ esto es lo que expone en los archivos de encabezado que envía con la aplicación.

ABI: Interfaz Binaria de Aplicación

Así es como el compilador crea una aplicación.
Define cosas (pero no está limitado a):

• Cómo se pasan los parámetros a las funciones (registros / pila).
• Quién limpia los parámetros de la pila (llamador / destinatario).
• Donde el valor de retorno se coloca para el retorno.
• Cómo se propagan las excepciones

Answer 2

( A plication B inary I nterface) Una especificación para una plataforma de hardware específica combinada con el sistema operativo. Está un paso más allá de la API (Interfaz del programa de aplicación), que define las llamadas de la aplicación al sistema operativo. El ABI define la API más el lenguaje de la máquina para una familia de CPU en particular. Una API no garantiza la compatibilidad de tiempo de ejecución, pero sí una ABI, ya que define el lenguaje de la máquina o el formato de tiempo de ejecución.

Courtesy

Answer 3

En general, me encuentro con estos términos en el sentido de un cambio incompatible con API o un cambio incompatible con ABI.

Un cambio de API es esencialmente donde el código que se habría compilado con la versión anterior ya no existirá. Esto puede suceder porque agrega un argumento a una función o cambia el nombre de algo accesible fuera de su código local. Cada vez que cambia un encabezado y lo obliga a cambiar algo en un archivo .c / .cpp, ha realizado un cambio de API.

Un cambio de ABI es cuando el código que ya se compiló con la versión 1 ya no funcionará con la versión 2 de una base de código (generalmente una biblioteca). En general, es más complicado realizar un seguimiento que el cambio incompatible con API, ya que algo tan simple como agregar un método virtual a una clase puede ser incompatible con ABI.

Encontré dos recursos extremadamente útiles para descubrir qué es la compatibilidad ABI y cómo preservarla:

• La lista de lo que se debe y lo que no se debe hacer con C ++ para el proyecto de KDE
• Ulrich Drepper''s How to Write Shared Libraries.pdf (autor principal de glibc)

Answer 4

La API es lo que los humanos usan. Escribimos el código fuente Cuando escribimos un programa y queremos usar alguna función de biblioteca escribimos código como:

 long howManyDecibels = 123L;
 int ok = livenMyHills( howManyDecibels);

y necesitábamos saber que hay un método livenMyHills() , que toma un parámetro entero largo. Entonces, como interfaz de programación, todo se expresa en el código fuente. El compilador convierte esto en instrucciones ejecutables que se ajustan a la implementación de este lenguaje en este sistema operativo particular. Y en este caso da como resultado algunas operaciones de bajo nivel en una unidad de Audio. Por lo tanto, bits y bytes particulares se rocían en algún hardware. Entonces en el tiempo de ejecución hay muchas acciones de nivel binario que normalmente no vemos.

Answer 5

Permítanme dar un ejemplo específico de cómo ABI y API difieren en Java.

Un cambio incompatible ABI es si cambio un método A # m () de tomar una String como argumento para el argumento String... Esto no es compatible con ABI porque tiene que volver a compilar el código que está llamando a eso, pero es compatible con API, ya que puede resolverlo recompilando sin ningún cambio de código en la persona que llama.

Aquí está el ejemplo explicado. Tengo mi biblioteca Java con clase A

// Version 1.0.0
public class A {
    public void m(String string) {
        System.out.println(string);
    }
}

Y tengo una clase que usa esta biblioteca

public class Main {
    public static void main(String[] args) {
        (new A()).m("string");
    }
}

Ahora, el autor de la biblioteca compiló su clase A, compilé mi clase Main y todo está funcionando muy bien. Imagina una nueva versión de A viene

// Version 2.0.0
public class A {
    public void m(String... string) {
        System.out.println(string[0]);
    }
}

Si tomo la nueva clase A compilada y la dejo junto con la clase compilada Principal, obtengo una excepción cuando intento invocar el método

Exception in thread "main" java.lang.NoSuchMethodError: A.m(Ljava/lang/String;)V
        at Main.main(Main.java:5)

Si recompilo Main, esto se soluciona y todo vuelve a funcionar.

Answer 6

Su programa (código fuente) se puede compilar con módulos que proporcionan la API adecuada.

Su programa (binario) puede ejecutarse en plataformas que proporcionan un ABI apropiado.

La API restringe las definiciones de tipos, las definiciones de funciones, las macros, a veces las variables globales que una biblioteca debe exponer.

ABI restringe lo que una "plataforma" debe proporcionarle a su programa para que se ejecute. Me gusta considerarlo en 3 niveles:

• nivel de procesador: el conjunto de instrucciones, la convención de llamadas

• kernel level: la convención de llamadas al sistema, la convención de ruta de archivos especial (por ejemplo, los archivos /proc y /sys en Linux), etc.

• Nivel de SO: el formato de objeto, las bibliotecas de tiempo de ejecución, etc.

Considere un compilador cruzado llamado arm-linux-gnueabi-gcc . "arm" indica la arquitectura del procesador, "linux" indica el kernel, "gnu" indica que los programas de destino usan la libc de GNU como biblioteca de tiempo de ejecución, diferente de arm-linux-androideabi-gcc que usa la implementación de libc de Android.

Answer 7

esta es mi explicación para el profano:

• api: piensa include archivos. ellos proveen una interfaz de programación
• abi - pensar en el módulo kernel. cuando lo ejecuta en algún núcleo, tienen que acordar cómo comunicarse sin incluir archivos, es decir, como una interfaz binaria de bajo nivel