LINUX.ORG.RU

Драйвер или демон?

 ,


2

2

Есть RaspberryPi к которому нужно подключить сложное устройство по spi. С этим устройством должны взаимодействовать несколько разных программ с пользовательского уровня. И есть два варианта контроллера - драйвер и демон. Драйвер очевидно управляется через пространство ядра, демон через доменный сокет.

Я вижу очень весомые преимущества демона: 1. Он работает со стандартным и очень удобным драйвером spi linux 2. Он имеет очень гибко настраиваемый интерфейс контроля в виде сокета. 3. В случае критических ошибок в коде демона, система останется работоспособной, а с драйвером все рухнет в тартарары.

Преимущества демона для меня очевидны. Я писал такие программы много раз и вполне успешно. Ну суть в том, что написание драйверов это для меня своего рода личный возов как для программиста (так как я это никогда не делал). Но поскольку задача вполне себе рабочая, я пытаюсь найти рациональные аргументы за написание именно драйвера. Вопрос - какие есть плюсы у драйвера относительно демона в срезе данной задачи?

Драйвер.

Концепция реализации уровня протокола работы со сложным устройством в ядре и предоставление интерфейса взаимодействия в юзерспэйс идеологически верная на мой взгляд.

spectral1989 ()
Ответ на: комментарий от spectral1989

Я в принципе мыслю похожим образом. Но у меня тогда обязуется вопрос. Вот есть драйвер spi, у него есть в юзерспейсе конечная точка в виде /dev/spidev. Насколько концептуально верна работа с устройством драйвера из кода другого драйвера. Потому как если этого не делать, то тогда работа с spi свалится до hal или даже до ассемблера. А это настолько усложнит задачу, что разработка драйвера станет рациональна только в целях повышения ЧСВ.

Serbis ()
Ответ на: комментарий от Serbis

нужно подключить сложное устройство по spi.

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

Вот есть драйвер spi, у него есть в юзерспейсе конечная точка в виде /dev/spidev

это интерфейс к контроллеру SPI (к “Controller Driver” в терминах документации ядра) для юзерспейс - на практике мало используемый

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

в ядре есть свой интерфейс для обмена сообщениями с SPI-контроллером он как раз и является основным, драйвер spidev тоже его использует а наружу торчит прослойка для юзера

разработка драйвера станет рациональна только в целях повышения ЧСВ

если твое устройство не требует обработки запросов на прерывание и нужно только тебе (нет стандартных библиотек/ПО) - можно и без драйвера

https://www.kernel.org/doc/html/latest/driver-api/spi.html

anonymous ()

3. В случае критических ошибок в коде демона, система останется работоспособной

Зато твое «сложное устройство» может не остаться.

а с драйвером все рухнет в тартарары.

Поэтому драйверы делают относительно небольшими и понятными.

tailgunner ★★★★★ ()
Ответ на: комментарий от Serbis

даже до ассемблера.

ассемблера

Нет

А это настолько усложнит задачу, что разработка драйвера станет рациональна только в целях повышения ЧСВ.

ЧСВ

Судя по твоим рассуждениям это и является целью - приобщиться к элите, лол

anonymous ()

не изобретай велосипед без особой необходимости. твой личный вызов юзеру не нужен. иначе он потом будет при каждом падении вызывать лично тебя :)

Iron_Bug ★★★★ ()
Ответ на: комментарий от spectral1989

Демон.

Драйвер управляется с портом, а с полезной нагрузкой которая стоит на этом порту пускай работает демон. Драйверы в ядро надо тащить только если узким местом становится userspace<->kernelspace копирование и всякие переключения контекста.

Nastishka ★★★★ ()

Все же пришел к выводу о том что драйвер. Железка это сс2530 с кастомной NP прошивкой. Из этого вытекает что: 1. Необходима полноценная работа с прерываниями. Работать с прерываниями со стороны юзерспейса, да еще с такой штукой как network processor это конечно фатальная глупость. 2. Задача полностью укладывается под определение протокольного драйвера, которые так же очень странно реализовывать как юзерспейс примочки.

Вообще суммируя все те тонны информации которые я перелопатил за последние несколько дней, я пришел к вот какому выводу - напрямую с железом должен работать только драйвер, наружу показывая минималистичный протокольный интерфейс. А все вот эти штуки вроде spidev и ttyS можно использовать только в отладочных целях или когда нужно по быстрому сварганить простую линию связи с мк. Во всех остальных случаях допустимы только модульные решения.

Serbis ()
Ответ на: комментарий от Serbis

Есть полно USB-устройств, драйвер для которых написан на libusb в юзерспейсе.

нужно подключить сложное устройство по spi.

1. Необходима полноценная работа с прерываниями.

Какие прерываения у SPI? Сигнал «у меня есть новые данные»? Так для того чтобы не было переполнения буфера, нужно подобрать подходящий размер и всё.

gag ★★★★★ ()
Ответ на: комментарий от gag

Какие прерываения у SPI? Сигнал «у меня есть новые данные»?

Ну как, их там несколько, ack пакеты, окончание сканирования, запросы на добавление в сеть, есть еще некоторые. Ну и кончено пресловутый «есть новые данные».

Я так резко поменял свое мнение потому, что поизучал тему. Почитал LDD, разобрал примеры, потыкал реальную железяку, поморгал светодиодом из ядра) И вот общее впечатление у меня сложилось такое. В первых меня удивило что код модулей, очень похож на прошивку с FreeRtos, местами прямо один в один. Те же ISR, таймеры, мьютексы и куча куча макросов. Для меня такая структура кода очень хорошо знакома. Во вторых я очень удивился, что страшное слово драйвер, на практике является относительно небольшой программой с очень очевидным потоком выполнения, с четкой точкой входа и выхода и понятными функциями. Если сравнивать тот же демон с unix domain, его код на мой взгляд куда запутаннее чем у модуля решающего те же самые задачи. В третьих я честно говоря не ожидал, что все подсистемы Raspberry Pi так легко достаются с уровня ядра и то что есть куча утильных функций и макросов позволяющих обходить большинство жестких ошибок, вроде захвата блокированного gpio и т п. Может быть я конечно в перспективе и ошибаюсь, но написание драйвера мне сейчас кажется значительно более удобоваримой задачей, нежели настраивание демонов поверх WiringPI...

Serbis ()