spidev - добро или зло?

Считаем, что все нужно по возможности тащить в юзерленд, если нет веских причин не тащить.

Но как вы считаете, тащить шины в юзерленд это хорошо, или наоборот плохо?

Как бы да, но как бы нет.

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

То есть: он будет доступен под теми же интерфейсами, с ним будет работать udev, с ним будет работать libinput, его будет видеть весь остальной софт. И наоборот: твоё приложение, скорее всего, будет работать с ним через стандартный интерфейс.

А если у тебя приложение напрямую дёргает пины через sysfs, то ты рукожоп и говноед, и едва устройство с твоим кодом окажется у меня на столе и мне нужно будет сделать с ним что-либо нестандартное (например, подменить устройство на фейковое, или вставить между приложением и железом какую-нибудь прослойку, или посниффать события), то у меня не останется других вариантов, кроме как не стесняясь в выражениях проклинать всех разработчиков и дизайнеров этого мусора.

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

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

А если у тебя приложение напрямую дёргает пины через sysfs, то ты рукожоп и говноед

А вот тут тебе обратный тейк, т.к в линухе до недавнего времени вообще не было нормального стандартизированного юзерспейс интерфейса для доступа к GPIO и ШИМ’у (для ШИМ’а и сейчас особо нет), везде своя проприетарщина. Глянь хотя-бы на малиновскую либу для броадкома, там прямо в юзерспейсе (!), программа пишет напрямую в регистры SoC (!!!), подобный доступ из юзерленда это вообще дичь. т.е понятно, что в идеале нужно пилить модуль (тем более апи линуха в этом плане максимально простое и удобное), но через sysfs раньше люди подобное делали не просто так…

https://github.com/janne/bcm2835/blob/master/bcm2835.c

Я лично видел еще один подход и отчасти считаю его говном: на медиатеках есть базовый драйвер (mtk-tpd для тача, mtk-fb для фреймбуфера и.т.п), которые организует эдакий фреймворк для фактической реализации тача/драйвера дисплея, которые потом уже выбираются в обход DT через atags/коммандлайн и.т.п

Кароч как по мне, отлаживать работу с модулями можно в юзерспейсе. Если этим модулям давать доступ другим людям - то лучше оформить это все в виде драйвера и дергать ioctl. Я так и собираюсь сделать с дисплеем на SPI - свой fb-драйвер + устройство lcdctrl, которому через ioctl можно установить яркость, включить/отключить и.т.п.

Я так и собираюсь сделать с дисплеем на SPI - свой fb-драйвер + устройство lcdctrl, которому через ioctl можно установить яркость, включить/отключить и.т.п.

Почему не backlight class?

Чет ты резко всех эмбедщиков под одну гребенку сгреб

Иначе срачегонного поста бы не получилось :-)

А вот тут тебе обратный тейк, т.к в линухе до недавнего времени вообще не было нормального стандартизированного юзерспейс интерфейса для доступа к GPIO

Да вроде всегда был — сначала sysfs ABI, потом (сейчас) его вообще задепрекейтили и теперь там character device с ioctl’ями. Но я не о том. Если у тебя пара пинов, которые никак не маппятся на высокоуровневые концепции (как переключение питания между USB-портом и mPCIe-модемом в микротиковских бордах), то вариантов особо нет. Но если у тебя устройство с человеческими кнопками, то я бы скорее хотел увидеть там input-драйвер, а не тупо приложение, которое лезет в GPIO руками — хоть через sysfs, хоть через /dev/gpiochip*.

и ШИМ’у (для ШИМ’а и сейчас особо нет)

https://www.kernel.org/doc/Documentation/pwm.txt, разве нет?

Я лично видел еще один подход и отчасти считаю его говном: на медиатеках есть базовый драйвер (mtk-tpd для тача, mtk-fb для фреймбуфера и.т.п), которые организует эдакий фреймворк для фактической реализации тача/драйвера дисплея, которые потом уже выбираются в обход DT через atags/коммандлайн и.т.п

Ну да.

В документации спидев написано что это только для прототипов, тоесть в продукции никогда. Зачем ты полез читать индусские статьи про их альтернативные восприятия и половые проблемы?

В RPi foundations тоже индусы получается?

Ещё один всё понял.

С одной стороны – добро, с другой – в кернеле всё-же какой никакой порядок, монорепа, единые интерфейсы сборки/инициализации. А драйвера в юзерленде каждый оформляет по-своему, получается зоопарк.

В идеале давно пора из дерева torvalds/linux собирать не только образ ядра, но и жирную юзерленд прослойку со всем подобным хозяйством – как это сделано в BSD. Например, объединить репозитории linux и systemd.

В ядре тоже весьма интересно все. Вот например есть у нас ko, который должен, ну пусть выводить фреймбуфер на дисплей Nokia 3310 (или пусть это будет виртуальный tty, куда ядро может писать лог - не имеет значения).

Учитывая, что концептуально это загружаемый драйвер только тогда, когда устройство присутствует, и ему может быть не нужна запись в machine-файлах/dts, но мейнтейнеры все равно называют говнокодом вызывать platform_add_device из module init.