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

Демон.

В ядро нужно тащить что-то только в том случае, если нельзя не затащить.

Аргументируй более развёрнуто

Драйвер.

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

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

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

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

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

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

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

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

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

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

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

пиши драйвер, один напишешь - разберешься, там все просто

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

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

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

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

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

ассемблера

Нет

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

ЧСВ

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

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

Демон.

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

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

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

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

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

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

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

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

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

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