Как Linux-сервер поддерживает огромное количество опций конфигурации?

Question

Этот вопрос касается обслуживания и тестирования конфигурации.

При неправильном использовании инструкции препроцессора #ifdef, #ifndef, #elseif, #elif, #else, #endif не только уменьшают удобочитаемость и ремонтопригодность C-кода, но также увеличивают риск ошибок регрессии (например, когда конкретная конфигурация сборки не тестировалась в течение определенного периода времени).

Мне интересно, как ядро ​​linux может поддерживать огромное количество опций конфигурации, не запускаясь в полный адский сервис?

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

Какие из следующих утверждений вы считаете истинными?

• Большинство производителей используют только набор стандартных конфигураций для их целевой платформы, так что большинство из возможных комбинаций конфигурации не являются ни испытания, ни использовали
• очень жесткое руководство кодирования существует, что позволяет ввести новый #ifdef's только для четко разделяемых частей кода, где имеет смысл отключить функцию (и правильные люди, ответственные за принятие этих решений)
• Есть так много тестеров для каждого нового выпуска ядра, что ошибки, связанные с конфигурацией, фиксируются во времени, поскольку большинство из них, вероятно, будут только строить регрессии

EDIT: Я понял, что есть тестовые машины, которые выбирают случайные конфигурации и проверяют, строят ли они и загружают. Тем не менее, эти простые сборки/загрузки-тесты не могут обнаружить каких-либо серьезных регрессий, кроме ошибок, которые ломают все.

Answer 1

Я работаю непосредственно с ядром Linux и «Das u-boot». Безусловно, у меня недостаточно опыта, но я дам ему шанс.

Насколько я могу судить, файл конфигурации, о котором вы говорите, на самом деле состоит из нескольких файлов, от большинства общих вещей, таких как архитектура процессора и т. Д., До очень подробных вещей, таких как частота RAM и тому подобное.

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

Не на 100% уверены, но я думаю, что вы правы, поскольку большинство поставщиков используют хотя бы некоторую стандартную конфигурацию. Например, представьте, что большинство смартфонов имеют одинаковую общую архитектуру HW (CPU, GPU, RAM и т. Д.), Поэтому нет необходимости настраивать абсолютно все.

Кроме того, да, основной код полон

#ifdef, #ifndef, #elseif, #elif, #else, #endif 

и это, очевидно, имеет свои преимущества и недостатки. Но это одна из прекрасных вещей о C (и C++), она позволяет управлять всем. Иногда выходите на помощь, иногда это настоящий кошмар.

ничего добавить о тестировании :)

Answer 2

проектов Linux и их Kernal не используют очередного обслуживания ту же структуру, что и другие Open Source Sofware обрабатывать различные аспекты управления конфигурацией.

Существует три элемента для поддержки ядра таким образом: создание репозитория, его обновление и поддержка, а также его интеграция в инфраструктуру построения.

Но отличия в архитектуре Linux и, как правило, обрабатываются в модулях, а комментарии журналов часто читаются в виде истории, описывая, как файл был разработан.

Код каждой версии находится в отдельном каталоге и применяет вклады и исправления к «последней» директории. Вклады могут быть применены только к репозитарию модераторами. Когда создается новый релиз, последний дублируется в новый каталог выпуска , чтобы сохранить его, даже если разработка продолжается.

Это причина, почему обычно вы видите только две ветви в разработке ядра Linux - одну ветвь стабильной версии и одну ветвь разработки.