Когда следует писать модуль ядра Linux?

Question

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

Это кажется мне странным. Когда следует рассмотреть возможность написания модуля ядра? Есть ли набор критериев?

Как я могу мотивировать сохранение кода в пространстве пользователя, которое (я считаю) там?

Answer 1

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

С одной стороны, отладка делается сложнее, а эффект ошибок намного хуже (авария/паника вместо простого coredump).

Answer 2

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

Answer 3

Есть очень ограниченные причины помещать вещи в ядро. Если вы пишете драйверы устройств, все в порядке. Любое стандартное приложение: никогда.

Недостатки огромны. Отладка становится сложнее, ошибки становятся все более частыми и трудными для поиска. Вы можете поставить под угрозу безопасность и стабильность. Возможно, вам придется чаще адаптироваться к изменениям ядра. Переход на другие ОС UNIX становится невозможным.

Ближайшим, я когда-либо приходил в ядро, была пользовательская файловая система (с mysql в фоновом режиме), и даже для этого мы использовали FUSE (где U обозначает пространство пользователей).

Answer 4

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

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

Answer 5

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

Что касается конкретных условий, которые вы должны проверить при рассмотрении кода режима ядра, вот несколько: нужен ли ему доступ к крайне низкоуровневым ресурсам, таким как прерывания?Является ли ваш код определяющим новый интерфейс/драйвер для оборудования, который не может быть построен поверх существующих в настоящее время функциональных возможностей? Ваш код требует доступа к структурам данных или примитивам, которые не экспортируются из пространства ядра? Вы пишете то, что будет в основном использоваться другими подсистемами, такими как планировщик или система VM (даже здесь не обязательно, чтобы подсистема была в режиме ядра: Mach имеет сильную поддержку пользовательский режим пейджерами виртуальной памяти, так что это может быть обязательно сделано)?

Answer 6

Если вашим людям нужен действительно высокий приоритет, детерминизм, низкая латентность и т. Д., Правильный путь - использовать некоторую версию Linux в реальном времени (или другую ОС).

Также обратите внимание на предпочтительные параметры ядра и т. Д. Точно, что вы должны делать, зависит от требований, но поместить код в модули ядра вряд ли будет правильным решением, если вы не подключаете какое-то оборудование напрямую.

Answer 7

Если вам нужна меньшая латентность, более высокая пропускная способность и т. Д., Вероятно, дешевле купить более быстрый компьютер, чем разрабатывать код ядра.

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

Но следует избегать перемещения больших частей вашей программы в пространство ядра, если все остальные варианты полностью не исчерпаны. Помимо трудности с этим, преимущество в производительности вряд ли будет очень большим.

Answer 8

В принципе, я согласен с rpj. Код должен быть в пользовательском пространстве, если только это НЕОБХОДИМО.

Но, чтобы подчеркнуть ваш вопрос, какое условие?

Некоторые люди утверждают, что драйвер должен находиться в ядре, что неверно. Некоторые драйверы не чувствительны к времени, на самом деле много драйверов.

Например, фреймер, таймер RTC, устройства i2c и т. Д. Эти драйверы можно легко перемещать в пространство пользователя. Есть даже некоторые файловые системы, написанные в пространстве пользователя.

Вы должны перейти в пространство ядра, где накладные расходы, например. user-kernel swap, становится неприемлемым для правильного функционирования вашего кода.

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

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

Но даже, скажем, вы имеете дело с SONET, и вам нужно сделать переключение защиты в течение 50 мс (на самом деле даже меньше, так как ограничение 50 мс распространяется на все кольцо), вы все равно можете переключиться очень быстро, ЕСЛИ ваше оборудование поддерживает его.

В настоящее время многие производители фреймов могут предоставить вам аппаратную поддержку, которая уменьшает количество записей, которые вам нужно делать. Ваша работа в основном реагирует на прерывание как можно быстрее. И Linux совсем не плох. Задержка прерывания, которую я получил, была меньше 1 мс, даже если у меня запущено множество других прерываний (например, IDE, ethernet и т. Д.).

И если этого еще недостаточно, то, возможно, ваш аппаратный дизайн неправильный. Некоторые вещи лучше оставить на аппаратном уровне. И когда я сказал аппаратное обеспечение, я имею в виду ASIC, FPGA, сетевой процессор или другую передовую логику.

Answer 9

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

Answer 10

Еще одна причина не переводить код в пространство ядра - это то, что, когда вы используете его в производственных или коммерческих ситуациях, вам придется опубликовать этот код из-за соглашения GPL. Ситуация, с которой многие софтверные компании не хотят входить. :)