Влияние вызова спящих функций, таких как set_current_state () / wait_event () в драйвере устройства? - PullRequest
Новая
       42

Влияние вызова спящих функций, таких как set_current_state () / wait_event () в драйвере устройства?

0 голосов
/ 09 октября 2018

Меня немного смущает, как работает модуль ядра после загрузки в ядро, в основном из-за вызовов функции sleep.

В качестве примера рассмотрим драйвер символьного устройства. Я видел код, подобный приведенному ниже, в read () функция, которая пытается перевести «процесс» в спящий режим с помощью set_current_state() (или иногда wait_event_interruptible() и т.читать (), устанавливая условие в true так: 

condition = true;
wake_up_process(task); // -> task was stored inside read() function

У меня есть следующие вопросы:

  1. Какой «процесс» выполняет set_current_state() или wait_event_interruptible()уложить спать здесь?Это процесс пользовательского пространства, который вызывает системный вызов read (), или какой-то процесс ядра, созданный для сопоставления процесса пользовательского пространства?

  2. Предполагается, что доступ к этому драйверу устройства ограничен только одним процессомустановив атомный счет в функции open (), и в драйвере устройства не разрешено прерывание, что произойдет, если read () вызовет wait_event () и другой процесс не сможет его разбудить?он застревает навсегда (потому что не прерываемый)?

  3. В чем разница между использованием set_current_state() и wait_event() API?Я видел разные фрагменты кода, использующие эти функции соответственно ... какие предпочтения нужно уделять одному другому?

1 Ответ

0 голосов
/ 09 октября 2018

  1. Код ядра выполняется в контексте "стороны ядра" потока пространства пользователя, который выполнил системный вызов.Каждый пользовательский поток имеет такой аналог пространства ядра.С точки зрения планировщика, пользовательская и ядровая части потока - это одна и та же сущность, поэтому, пока поток ядра запланирован, пользовательский поток также.

  2. "Прерываемый" и«Непрерывное» ожидание отличается способом обработки сигналов.Когда процесс находится в состоянии TASK_INTERRUPTIBLE и получает сигнал, система гарантирует, что он выйдет из schedule () как можно скорее.После этого сам процесс должен выйти из цикла ожидания, если signal_pending () вернет true.В примере кода в тексте вопроса это не реализовано должным образом, если 'условие' не является выражением, содержащим проверку signal_pending ().

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

...