Empecé a pensar en este tema en el contexto de la etiqueta en la lista de correo del kernel de Linux. Como el proyecto de software libre más conocido y posiblemente más exitoso e importante del mundo, el kernel de Linux recibe mucha prensa. Y el fundador y líder del proyecto, Linus Torvalds, claramente no necesita presentación aquí.
Linus ocasionalmente genera controversia con sus llamas en la LKML. Estas llamas con frecuencia, por su propia admisión, tienen que ver con romper el espacio del usuario. Lo que me lleva a mi pregunta.
¿Puedo tener una perspectiva histórica sobre por qué romper el espacio del usuario es algo tan malo? Tal como lo entiendo, romper el espacio del usuario requeriría correcciones en el nivel de la aplicación, pero ¿es esto algo tan malo si mejora el código del kernel?
Según tengo entendido, la política declarada de Linus es que no romper el espacio del usuario supera todo lo demás, incluida la calidad del código. ¿Por qué es esto tan importante y cuáles son los pros y los contras de tal política?
(Claramente, hay algunas desventajas en tal política, aplicada consistentemente, ya que Linus ocasionalmente tiene "desacuerdos" con sus principales lugartenientes en la LKML exactamente sobre este tema. Por lo que puedo decir, siempre se sale con la suya en el asunto).
Respuesta aceptada:
La razón no es histórica sino práctica. Hay muchos, muchos, muchos programas que se ejecutan sobre el kernel de Linux; si una interfaz del kernel rompe esos programas, entonces todos deberían actualizar esos programas.
Ahora bien, es cierto que la mayoría de los programas no dependen directamente de las interfaces del núcleo (las llamadas al sistema), sino solo de las interfaces de la biblioteca estándar de C (envolturas de C alrededor de las llamadas al sistema). Ah, pero ¿qué biblioteca estándar? ¿Glibc? uClibC? Dietlibc? ¿Biónico? ¿Musul? etc.
Pero también hay muchos programas que implementan servicios específicos del sistema operativo y dependen de las interfaces del kernel que no están expuestas por la biblioteca estándar. (En Linux, muchos de estos se ofrecen a través de /proc y /sys .)
Y luego están los binarios compilados estáticamente. Si una actualización del kernel rompe uno de estos, la única solución sería volver a compilarlos. Si tiene la fuente:Linux también admite software propietario.
Incluso cuando la fuente está disponible, reunirlo todo puede ser una molestia. Especialmente cuando está actualizando su kernel para corregir un error con su hardware. Las personas a menudo actualizan su kernel independientemente del resto de su sistema porque necesitan soporte de hardware. En palabras de Linus Torvalds:
Romper los programas de usuario simplemente no es aceptable. (…) Sabemos que la gente usa binarios antiguos durante años y años, y que hacer un nuevo lanzamiento no significa que puedas tirarlo. Puedes confiar en nosotros.
También explica que una de las razones para hacer de esto una regla estricta es evitar el infierno de la dependencia en el que no solo tendría que actualizar otro programa para que funcione un kernel más nuevo, sino que también tendría que actualizar otro programa, y otro, y otro. , porque todo depende de una determinada versión de todo.
Es algo ok para tener una dependencia unidireccional bien definida. Es triste, pero inevitable a veces. (…) Lo que NO está bien es tener una dependencia bidireccional. Si el código HAL del espacio de usuario depende de un nuevo núcleo, está bien, aunque sospecho que los usuarios esperarían que no fuera el "núcleo de la semana", sino más bien un "núcleo de los últimos meses".
Pero si tienes una dependencia de DOBLE VÍA, estás jodido. Eso significa que tiene que actualizar en el paso de bloqueo, y eso simplemente NO ES ACEPTABLE. Es horrible para el usuario, pero lo que es más importante, es horrible para los desarrolladores, porque significa que no puedes decir "ocurrió un error" y hacer cosas como tratar de reducirlo con una bisección o algo similar.
En el espacio de usuario, esas dependencias mutuas generalmente se resuelven manteniendo diferentes versiones de la biblioteca; pero solo puede ejecutar un kernel, por lo que debe ser compatible con todo lo que la gente quiera hacer con él.
Relacionado:¿Explicación del orden de clasificación?Oficialmente,
Se garantizará la compatibilidad con versiones anteriores de [llamadas al sistema declaradas estables] durante al menos 2 años.
Sin embargo, en la práctica,
Se espera que la mayoría de las interfaces (como las llamadas al sistema) nunca cambien y siempre estén disponibles.
Lo que cambia con más frecuencia son las interfaces que solo están destinadas a ser utilizadas por programas relacionados con el hardware, en /sys . (/proc , por otro lado, que desde la introducción de /sys se ha reservado para servicios no relacionados con el hardware, casi nunca se rompe de manera incompatible).
En resumen,
romper el espacio del usuario requeriría arreglos en el nivel de la aplicación
y eso es malo porque solo hay un kernel, que la gente quiere actualizar independientemente del resto de su sistema, pero hay muchas aplicaciones con interdependencias complejas. Es más fácil mantener el núcleo estable que mantener miles de aplicaciones actualizadas en millones de configuraciones diferentes.