Изменить файловые операции на зарегистрированном символьном устройстве в Linux - PullRequest
Новая
       37

Изменить файловые операции на зарегистрированном символьном устройстве в Linux

0 голосов
/ 07 июля 2019

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

Я бы предпочел использовать дополнительный модуль ядра.Однако модуль загружается другим модулем (то есть его init_function вызывается другим модулем).

То, что мне нужно изменить, - это реализация функции .write в file_operations.

Стратегия может состоять в том, чтобы отменить регистрацию chardev и перерегистрировать его с помощью модифицированной функции .write после загрузки в ядро ​​пользовательского модуля.Это законная стратегия?Есть ли примеры кода для этого?

Я хотел бы изменить следующую строку в drivers / media / rc / lirc_dev.c: 

#define LIRCBUF_SIZE    256

на 

#define LIRCBUF_SIZE    1024

По сути, мне нужен более длинный буфер, чтобы избежать возврата EINVAL в строке 330 

if (count > LIRCBUF_SIZE || count % 2 == 0) {
  ret = -EINVAL;
  goto out_unlock;
}

. Lirc_dev регистрирует символьные устройства / dev / lirc0, / dev / lirc1 и т. Д., А строки выше взяты изреализация .write структуры file_operations.
Регистрация запускается модулями rc_core с lirc_dev_init, кажется, и я также хочу избежать использования пользовательской реализации rc_core.

Я уже сделалпользовательская модификация в инструментах пространства пользователя lirc, которые также имеют это ограничение буфера в 256 единиц (= int), но оно прерывается в тот момент, когда драйвер lirc выполняет «запись» на устройство «/ dev / lirc0» сошибка ввода-вывода.

Стратегия написания 256 int chunks по существу работала бы, но она деликатна, и я не думаю, что смогу заставить ее работать с аппаратным обеспечением из-за проблем с синхронизацией.(когда «запись» в пространство ядра фактически вызывает некоторые аппаратные действия ...)

Все это кажется слишком сложным, если все, что я хочу сделать, это увеличить буфер ...

1 Ответ

0 голосов
/ 07 июля 2019

"Это законная стратегия?" - нет Это интересно, но я уверен, что это не законно. Если я понимаю, что вы хотите перехватить / dev / lirc ?, это может быть проще сделать, переписав узлы устройства для / dev / lirc ?, что Я думаю, все еще вещь.

Традиционные узлы устройств UNIX содержат два числа, старшее и младшее. Когда вы открываете ("/ dev / lirc2" ...), ядро ​​извлекает основной номер и извлекает экземпляр устройства из таблицы сопоставления. Затем он вызывает методы в этом случае для работы на устройстве (открытие, закрытие, чтение, запись, ioctl, ..).

Утилита mknod может использоваться для создания записей устройства, поэтому я считаю, что: 

mv /dev/lirc2 /dev/olicr2 && mknod c /dev/lirc2 ${major} 2

позволит вам перенаправить / dev / lirc2 на новое устройство.

Я пролистал около 10 глав деталей; включая то, как получить цифры для вас $ {major}, и я не уверен, как файловая система myriad / sys отреагирует на такого рода злоупотребления, но это приводит к другому вопросу:

Зачем вам нужно больше буферного пространства в lirc? На первый взгляд кажется, что может быть более простой способ достичь своей цели с гораздо меньшими затратами сантехники ...

...