Опрос контрольного регистра устройства в пользовательском пространстве для проверки ошибок

Я пишу код для регистрации ошибок в пользовательском пространстве, возникающих на устройстве PCI (ядро уже регистрирует их в кольцевом буфере ядра). В настоящее время у меня есть два подхода передо мной,

  1. Измените драйвер устройства ядра, чтобы отправить прерывание в мой процесс пользовательского пространства (используя eventfd), а затем, получив это прерывание (используя select() или poll()), я могу получить подробную информацию об ошибке, используя ioctl (потребуется изменение в драйвере устройства ). Это требует изменений в коде ядра, которых я хотел бы избежать.

  2. Мой процесс работает как root, поэтому я могу читать/записывать регистры состояния ошибок устройства, используя sysfs. Для этого мне придется постоянно опрашивать регистры, и как только произойдет ошибка, я смогу прочитать регистр состояния, расшифровать его, получить подробную информацию об ошибке, а затем очистить регистры.

Я больше склоняюсь ко второму подходу, так как он требует изменений только в пользовательском пространстве.

Мои вопросы:

  1. Имеет ли смысл второй подход?
  2. Если да, то каковы плюсы и минусы обоих подходов?
  3. Опрос во втором подходе приведет к пустой трате циклов ЦП. Приводит ли использование select() или poll() в первом подходе к потерям циклов ЦП в аналогичных пропорциях.

Полезный ответ будет принят с благодарностью! :)


linux-kernel kernel linux-device-driver sysfs pci
person user2330697    schedule 23.10.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

  1. Второй подход - уродливая мерзость. Имеет ли это смысл в ваших конкретных обстоятельствах, решать только вам.

  2. Задача драйвера — инкапсулировать и контролировать доступ к оборудованию. При втором подходе и драйверу, и процессу может потребоваться знать, что другой может мешать работе устройства.

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

  3. Драйвер будет тратить процессор впустую, если будет опрашивать устройство в цикле. С прерыванием ЦП может спать.

person CL.    schedule 25.10.2013

arrow_upward
0
arrow_downward

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

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

person pdssn    schedule 25.02.2016