ventajas - ¿Por qué el núcleo de Linux está codificado utilizando C no estándar(características específicas de gcc)?
ventajas y desventajas de linux (4)
¿Por qué los desarrolladores del kernel de Linux se preocupan por hacer que su código funcione en, por ejemplo, el compilador Microsoft Visual Studio o los compiladores IBM xlC?
Cuando estás escribiendo un kernel, necesitas un control muy preciso sobre muchas más cosas, como el diseño de memoria exacto, que el que tienes (generalmente) en el espacio de usuario. Dichos controles realmente no se tienen en cuenta en el estándar C (dejados como características definidas por la implementación, por ejemplo), por lo que o bien son necesarias algunas extensiones o debe confiar en las peculiaridades del compilador.
Quedarse con un compilador específico, aprovechando sus extensiones, es una decisión racional. El código no necesita ser portátil en los compiladores, debe ser eficiente y portátil en diferentes plataformas de hardware.
El código del kernel de Linux utiliza la "expresión-expresión" y la extensión typeof que lo hace solo compilable bajo gcc.
Más lo pienso, más no tiene sentido.
Derrota el propósito de la portabilidad y el estándar C. (ahora el código del kernel de Linux necesita un compilador específico que admita las extensiones gcc).
¿Fue una mala elección de diseño o hubo una razón específica para hacer que el código del kernel de Linux sea específico para gcc?
EDITAR: Cuando dije que vencía la portabilidad, lo usé en un contexto diferente. Estaba pensando que, al cumplir con el estándar C, se aceptaría en CUALQUIER compilador que admita el estándar C (que es exactamente el propósito de crear un estándar: unificar todos los dialectos diferentes de C), por lo que es más portátil. Por supuesto, dado que gcc es tan popular, y gcc es compatible con millones de arquitecturas, esta línea carece de sentido. Solo pregunto si había una razón específica detrás de no cumplir con el estándar C.
Aquí hay algunos buenos antecedentes sobre las extensiones específicas utilizadas. Realmente no está escrito desde la perspectiva de "¿por qué?", Pero debería ofrecerle una buena base sobre los motivos para elegir este enfoque:
http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/
El código del kernel de Linux es una pieza de software complicada. Cuantas más facilidades les proporcione gcc, más felices estarán los programadores.
¿Por qué les importaría la portabilidad? gcc compila el código en prácticamente todas las configuraciones de hardware MÁS que les proporciona buenas características. ¿Por qué les importaría si Linux podría o no podría compilarse con otro compilador?
Hoy en día, el código portátil es un concepto tan común para nosotros que creemos que debería existir en todas partes. Pero ese no es el caso. Por ejemplo, si un compilador proporciona extensiones en tiempo real a C, la NASA lo usaría sin importar la portabilidad. El punto importante es que las características son demasiado buenas para sacrificarlas para una portabilidad que nunca se usa (quiero decir, ¿quién compilaría el kernel con MS Visual Studio por ejemplo?)
Una vez que se compila el kernel, no deja "rastros" de su entorno de compilación alrededor para contaminar la experiencia del kernel en ejecución.
Yo diría que es sólo una cuestión de conveniencia. El kernel también contiene partes de ensamblaje, y el ensamblaje tampoco es exactamente portátil. Quizás si la "misión" del kernel era escribir un kernel que pudiera compilarse en múltiples compiladores de C, la queja caería en oídos más atentos.