Ioctl -> sysfs migration

про ioctl это он загнался, имхо. хотя... покури что-нибудь про inferno

ioctl плох тем, что это не open-read-write файловый интерфейс. Его сложно использовать из того же bash, а sysfs - без проблем, ибо это обычный файловый интерфейс.

> Его сложно использовать из того же bash, а sysfs - без проблем, ибо это обычный файловый интерфейс

Правильнее уж тогда говорить, что в данном случае баш плох тем, что не поддерживает ioctl,

в том же перле такая возможность есть. Да и сделать, чтобы в баше можно было использовать ioctl, -

5 минут, написать утилиту на C. А при реализации общения с драйвером только через sysfs

получится такое нагромождение kobject-ов и всяких других структур, что рад не будешь, что вообще с sysfs связался.

Потом, как ты будешь команду передавать? Через буфер? Это уже будет костыль.

А если я вообще у себя не стану монтировать sysfs?

В своих проектах часто юзаю sysfs вместо ioctl. С kobject-ами да, намудрено неслабо, однако, архитектура строится правильнее, так как приходится на них ориентироваться. Но в целом, ioctl проще, поэтому я от него совсем не отказываюсь.

Насколько мне известно, ioctl считается не очень хорошим потому, что команды (номера вызова) хранятся к глобальном пространстве имён. Придуманы всякие макросы для генерации уникальных номеров, но это не решение, а лишь подспорье. Зато удобно, передав указатель на структуру, считать её целиком и не запариваться. Как в таком случае поступать с sysfs? - для каждого поля структуры создавать файл с её значением??? А если их дофига этих полей и структуры вложенные?? Отдельно считывать каждое поле?? На производительности, конечно мало скажется (фс всё-таки в оперативке висит), но код получится в таком случае чудовищный... Или я что-то не так понимаю??

> С kobject-ами да, намудрено неслабо, однако, архитектура строится правильнее

Когда у тебя какой-то объект ядра удаляется через посылку уведомления kobject-у, это сложно
назвать правильной архитектурой. К чему все эти усложнения? Посмотри, например, код драйверов ide и sci -
там сам чёрт ногу сломит поначалу. Вообще sysfs предназначена изначально для предоставления
информации о зарегистрированных аппаратных интерфейсах и подключённых к ним устройствах, их параметрах.
Добавление туда управляющей логики вместо ioctl - концептуальное противоречие.

> sci

scsi конечно же