Возможно ли связать 2 модуля ядра с одним и тем же /dev/device?

Я хочу смоделировать дорогое устройство с помощью программного макета (мы называем его (B)), взаимодействующего с /dev/device вместо реального устройства.

В настоящее время уже существует модуль ядра для управления реальным устройством, которое связано с /dev/device (мы называем его (A)).

Возможно ли, что (A) отправляет данные на /dev/device и что (B) читает эти данные, готовит ответ и отправляет его обратно на /dev/device, и что (A) читает это отклик ?

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


module linux kernel device driver
person Fabien    schedule 14.02.2013    source источник
comment
Так это (Б) макет или реальное устройство? Если я правильно понимаю, смысл в том, чтобы создать симуляцию в пользовательском пространстве, чтобы она могла взаимодействовать с модулем ядра (A) через dev/device?   -  person KBart    schedule 14.02.2013
comment
Попробуйте посмотреть umockdev< /а>.   -  person Antoine    schedule 14.02.2013
comment
@KBart (B) - это программный макет, а не реальное устройство, а имитация этого устройства, которого у меня нет. И да, я хочу общаться через /dev/device   -  person Fabien    schedule 14.02.2013
comment
@Antoine Антуан, я посмотрю на umockdev, если он соответствует моим потребностям.   -  person Fabien    schedule 14.02.2013
comment
@Antoine Макет уже закодирован, umockdev, похоже, нужно снова закодировать его на Python. Это может быть решением, но в долгосрочной перспективе, если нет ответа на этот вопрос.   -  person Fabien    schedule 14.02.2013
comment
@Fabien, трудно сказать, не зная, что на самом деле делает ваше устройство/драйверы, но я бы выбрал такой подход: подключите второй компьютер с использованием исходного интерфейса (A) или направьте его на любой другой (UART, USB и т. д.) на второй компьютер демонизирует ваш макет (B) и подключается к соответствующему dev/interface. Насколько я понимаю, вы хотите проверить это устройство на уровне протокола, поэтому базовый интерфейс не имеет значения. Это будет выглядеть так: (Б)]   -  person KBart    schedule 15.02.2013
comment
@KBart спасибо за ваше решение. Я буду иметь ввиду. Однако я бы предпочел использовать только один ПК. Это делается для того, чтобы избежать усложнения тестовой архитектуры за счет полного ПК, имитирующего маленькое устройство. Кстати, я исследую взлом модуля ядра (A), чтобы подключить его код к макету (B) и поместить код в #ifdef #endif для тестов.   -  person Fabien    schedule 15.02.2013
comment
@Fabien, и цель состоит в том, чтобы протестировать / отладить ваш kmodule (A)? Если да, то что именно? Если это драйвер устройства, у него есть 2 интерфейса: нижний, который подключает устройство через некоторый физический интерфейс, и верхний, который предоставляет API (/dev/device) для пользовательского пространства; так какая часть вашего внимания? Или речь только о внутренней логике (А) и интерфейсы вообще не имеют значения?   -  person KBart    schedule 15.02.2013
comment
Цель @KBart состояла в том, чтобы использовать тот же kmodule (A), но заменить реальное устройство программным обеспечением. Итак, с вашим объяснением, я полагаю, мне придется изменить нижнюю часть kmodule для отправки смоделированной информации в upper/dev/device. Я думаю, что мне придется изучить больше этой части. Спасибо.   -  person Fabien    schedule 19.02.2013
comment
@Fabien взгляните на LDD3 — если вы еще не видели его раньше — это один из лучшие отправные точки для драйверов устройств ядра.   -  person KBart    schedule 19.02.2013

Ответы (1)


arrow_upward
2
arrow_downward

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

person ravi bhuva    schedule 19.02.2013