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

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

В принципе, я согласен с RPJ. Код должен находиться в пользовательском пространстве, если это НЕ ДЕЙСТВИТЕЛЬНО необходимо.

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

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

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

Вы должны перейти в пространство ядра, где накладные расходы, например. своп пользовательского ядра становится неприемлемым для правильной работы вашего кода.

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

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

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

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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

Answer 8

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

Answer 9

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

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

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

Answer 10

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

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