Почему ядро Linux кодируется с использованием нестандартных функций C (gcc)?

В коде ядра Linux используется выражение "statement-expression" и typeof extension, что делает его только компилируемым под gcc.

Больше я думаю об этом, больше это не имеет смысла.

Это побеждает цель переносимости и стандартного C. (теперь для Linux-кода ядра нужен специальный компилятор, который поддерживает расширения gcc).

Было ли это неправильным выбором дизайна или была ли конкретная причина для создания кода ядра Linux, специфичного для gcc?

EDIT: Когда я сказал, что это побеждает переносимость, я использовал его в другом контексте. Я думал, что в соответствии со стандартом C он будет принят ЛЮБОЙ компилятор, который поддерживает стандарт C (который является именно целью создания стандарта - унифицировать все разные диалекты C), следовательно, быть более переносимым. Конечно, поскольку gcc настолько популярен, и gcc поддерживает zillion архитектуры, эта линия почти бессмысленна. Я просто спрашиваю, существует ли конкретное обоснование, не соответствующее стандарту C.

Ответ 1

Почему разработчики ядра Linux будут беспокоиться о том, чтобы заставить их работать над компилятором Microsoft Visual Studio или компиляторами IBM xlC?

Когда вы пишете ядро, вам нужен очень точный контроль над гораздо большим количеством материалов, например точной макетом памяти, чем вы (обычно) в пользовательском пространстве. Такие элементы управления на самом деле не учитываются в стандарте C (например, как определенные для реализации характеристики), поэтому необходимы либо некоторые расширения, либо вам нужно полагаться на причуды компилятора.

Придерживаясь одним конкретным компилятором, пользуясь его расширениями, это рациональное решение. Код не должен быть переносимым для всех компиляторов - он должен быть эффективным и переносимым на разных аппаратных платформах.

Ответ 2

Вот хороший фон для конкретных расширений. На самом деле он написан не с точки зрения "почему?", Но он должен дать вам хорошее представление о причинах выбора этого подхода:

https://developer.ibm.com/tutorials/l-gcc-hacks/

Ответ 3

Код ядра Linux - сложная часть программного обеспечения. Чем больше возможностей gcc предоставляет им, тем они счастливее будут кодеры.

Почему они заботятся о переносимости? gcc компилирует код практически во всех аппаратных конфигурациях PLUS, он предоставляет им хорошие возможности. Почему им было бы интересно, если Linux мог или не мог быть скомпилирован с другим компилятором?

Сегодня переносимый код - это такая общая концепция для нас, что мы считаем, что он должен существовать повсюду. Но это не тот случай. Например, если компилятор предоставляет расширения в режиме реального времени для C, NASA будет использовать его без забот о переносимости. Важным моментом является то, что функции слишком хороши для жертвоприношения для переносимости, которая никогда не используется (я имею в виду, кто будет компилировать ядро с MS Visual Studio, например?)

Ответ 4

Как только ядро скомпилировано, оно не оставляет "следов" его среды компиляции, чтобы испортить работу запущенного ядра.

Я бы сказал, это просто вопрос целесообразности. Ядро также содержит биты сборки, а сборка также не является переносимой. Возможно, если "миссия" ядра заключалась в том, чтобы написать ядро, которое может быть скомпилировано на нескольких компиляторах C, жалоба будет падать более внимательными ушами.