LINUX.ORG.RU
Форум — Development  

Ioctl -> sysfs migration


0

0
Читаю тут Роберта Лава: "Разработка ядра Linux". Так вот, если я го правильно понял, он утверждает, что ioctl и procfs это не тру, а sysfs - наше фсио. При этом оговаривается, сто каждый файл в sysfs (атрибут) должен содекжать единственное значение, желательно стандартного С-типа. Ну, или в крайнем случае, набор однотипных значений, разделённых пробелами. Я пользовал ioctl, а вот с kobject и иже с ним сталкивался лишь мельком. Предварительный гуглёж ничего вразумительного не дал. Хотелось бы услышать от тех, кто пробовал реализовать более менее сложное общение с драйвером исключительно через sysfs. Как, например, со структурами, хранящими значение быть и т.д. ... вобщем как вообще это должно по идее выглядеть?
anonymous
← Влияние флагов оптимизации на результаты исполнения программы
Хостинг →
Ответ на: комментарий от cobold
ioctl плох тем, что это не open-read-write файловый интерфейс. Его сложно использовать из того же bash, а sysfs - без проблем, ибо это обычный файловый интерфейс.
krum ★
()
Ответ на: комментарий от krum
> Его сложно использовать из того же bash, а sysfs - без проблем, ибо это обычный файловый интерфейс

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

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

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

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

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

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

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

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

Agent666
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Влияние флагов оптимизации на результаты исполнения программы
Development
Хостинг →