Некоторые люди хотят по какой-то причине переместить код из пользовательского пространства в пространство ядра в Linux. Много раз причина заключается в том, что код должен иметь особенно высокий приоритет или просто "пространство ядра быстрее".
Мне это кажется странным. Когда следует рассмотреть возможность написания модуля ядра? Есть ли набор критериев?
Как я могу мотивировать сохранение кода в пользовательском пространстве, которое (я считаю) там?
Правило большого пальца: попробуйте использовать ваш абсолютный лучший, чтобы сохранить код в пользовательском пространстве. Если вы не думаете, что можете, потратьте столько времени на изучение альтернатив коду ядра, как написание кода (т.е. Долгое время), а затем повторите попытку реализовать его в пользовательском пространстве. Если вы все еще не можете, исследуйте больше, чтобы убедиться, что вы делаете правильный выбор, а затем очень осторожно переходите в ядро. Как говорили другие, очень мало обстоятельств, которые диктуют писать модули ядра и отлаживать код ядра, могут быть довольно адскими, поэтому избегайте любой ценой.
Что касается конкретных условий, которые вы должны проверить при рассмотрении кода режима ядра, вот несколько: нужен ли ему доступ к крайне низкоуровневым ресурсам, таким как прерывания? Является ли ваш код определяющим новый интерфейс/драйвер для оборудования, который не может быть построен поверх существующих в настоящее время функций? Требует ли ваш код доступ к структурам данных или примитивам, которые не экспортируются из пространства ядра? Вы пишете то, что будет в основном использоваться другими подсистемами ядра, такими как планировщик или система VM (даже здесь не обязательно, чтобы подсистема была в режиме ядра: Mach имеет сильную поддержку пейджеров виртуальной памяти пользовательского режима, так что это определенно можно сделать)?
Есть очень ограниченные причины помещать вещи в ядро. Если вы пишете драйверы устройств, все в порядке. Любое стандартное приложение: никогда.
Недостатки огромны. Отладка становится сложнее, ошибки становятся все более частыми и трудными для поиска. Вы можете поставить под угрозу безопасность и стабильность. Возможно, вам придется чаще адаптироваться к изменениям ядра. Переход на другие ОС UNIX становится невозможным.
Ближайшим я когда-либо приходил в ядро, была пользовательская файловая система (с mysql в фоновом режиме), и даже для этого мы использовали FUSE (где U обозначает пространство пользователей).
Я не уверен, что вопрос правильный. Должна быть веская причина переместить вещи в пространство ядра. Если нет причин, не делайте этого.
С одной стороны, отладка становится сложнее, а эффект ошибок намного хуже (авария/паника вместо простого coredump).
Код, выполняющийся в ядре, обращается к памяти, периферийным устройствам, системным функциям способами, отличными от кода пользовательского пространства, и, следовательно, имеет возможность быть более эффективным. Не говоря уже об уменьшенных ограничениях безопасности для кода ядра. Тем не менее, все это обычно связано с затратами, такими как увеличение возможности открытия ядра до угроз безопасности, блокировка ОС, усложнение отладки и т.д.
В принципе, я согласен с rpj. Код должен быть в пользовательском пространстве, если это НЕОБХОДИМО.
Но, чтобы подчеркнуть ваш вопрос, какое условие?
Некоторые люди утверждают, что драйвер должен находиться в ядре, что неверно. Некоторые драйверы не чувствительны к времени, на самом деле многие драйверы такие.
Например, фреймер, таймер RTC, устройства i2c и т.д. Эти драйверы можно легко перемещать в пространство пользователя. Есть даже некоторые файловые системы, которые написаны в пользовательском пространстве.
Вы должны перейти в пространство ядра, где накладные расходы, например. user-kernel swap, становится неприемлемым для правильного функционирования вашего кода.
Но есть много способов справиться с этим. Например, /dev/mem предоставляет хороший способ доступа к вашей физической памяти, так же, как вы делаете это из пространства ядра.
Когда люди говорят о переходе на RTOS, я обычно скептически отношусь. В наши дни процессор настолько мощный, что в большинстве случаев аспект в реальном времени становится ничтожным.
Но даже, скажем, вы имеете дело с SONET, и вам нужно сделать переключение защиты в течение 50 мс (на самом деле даже меньше, поскольку ограничение 50 мс распространяется на все кольцо), вы все равно можете очень быстро переключаться, ЕСЛИ ваше оборудование поддерживает его.
В настоящее время множество фреймов может предоставить вам аппаратную поддержку, которая уменьшает количество записей, которые вам нужно делать. Ваша работа в основном реагирует на прерывание как можно быстрее. И Linux совсем не плох. Задержка прерывания, которую я получил, была меньше 1 мс, даже если у меня есть множество других прерываний (например, IDE, ethernet и т.д.).
И если этого еще недостаточно, возможно, ваш дизайн аппаратного обеспечения неправильный. Некоторые вещи лучше оставить на аппаратном уровне. И когда я сказал аппаратное обеспечение, я имею в виду ASIC, FPGA, сетевой процессор или другую передовую логику.
Если вашим людям нужен действительно высокий приоритет, детерминизм, низкая латентность и т.д., правильный путь - использовать некоторую версию Linux (или другой ОС) в режиме реального времени.
Также посмотрите на предпочтительные параметры ядра и т.д. Точно то, что вы должны делать, зависит от требований, но поставить код в модули ядра вряд ли будет правильным решением, если вы не взаимодействуете с некоторым оборудованием напрямую.
Как правило. Подумайте о том, что вы хотите знать, и если это то, что вы увидите в книге или классе разработки операционной системы, то у нее есть хороший шанс попасть в ядро. Если нет, держите его вне ядра. Если у вас есть веская причина нарушить это правило, убедитесь, что у вас будет достаточно знаний, чтобы знать это самостоятельно или вы будете работать с кем-то, у кого есть эти знания.
Да, может показаться резким, но это именно то, что я имел в виду, если вы не знаете, тогда почти наверняка ответ будет отрицательным, не делайте этого в ядре. Перемещение вашей разработки на пространство ядра открывает гигантскую банку червей, с которой вы, несомненно, сможете справиться.
Еще одна причина не переводить код в пространство ядра - это то, что когда вы используете его в производственных или коммерческих ситуациях, вам придется опубликовать этот код из-за соглашения GPL. Ситуация, с которой многие софтверные компании не хотят входить.:)
Если вам просто нужна более низкая задержка, более высокая пропускная способность и т.д., вероятно, дешевле купить более быстрый компьютер, чем разрабатывать код ядра.
Модули ядра могут быть более быстрыми (из-за меньшего количества коммутаторов контекста, меньших издержек системного вызова и меньших перерывов) и, безусловно, работают с очень высоким приоритетом. Если вы хотите экспортировать небольшое количество довольно простого кода в пространство ядра, это может быть ОК. То есть, если обнаружится, что небольшой фрагмент кода имеет решающее значение для производительности, и это тот код, который будет полезен для размещения в режиме ядра, тогда может быть обосновано его размещение.
Но перемещение больших частей вашей программы в пространство ядра следует избегать, если все остальные параметры полностью не исчерпаны. Помимо трудности с этим, преимущество в производительности вряд ли будет очень большим.
Если вы задаете такой вопрос, вам не следует идти на уровень ядра. В основном просто интересно, что вам не нужно. Время переключения контекста настолько незначительно, что в наши дни это не имеет значения.