|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Victor Wagner 2:5020/400 21 Dec 2004 01:13:55
To : Zahar Kiselev
Subject : Re: драйвер
--------------------------------------------------------------------------------
Zahar Kiselev <Zahar.Kiselev@p1.f382.n5030.z2.fidonet.org>
wrote:
ZK> Hello Victor!
ZK> Dec 20 19:02 04, Victor Wagner wrote to Zahar Kiselev:
ZK>>>входных каналов там может быть от задействовано от 1 до
32,
ZK>>>это можно выбирать и выбор я "повесил" на отдельный
ioctl.
VW>> Hу и сделай 32 символьных устройства. С общим major и
VW>> разными minor. И на каждое из них выдавай данные только
VW>> из одного канала. Все равно больше восьми таких карт
VW>> одновременно у тебя вряд ли будет.
ZK> Технически не вижу проблемы. Однако как такое
ZK> монстрообразие соотносится с идеологией и стилем?
Да нормально. У тебя есть поток данных. Он представляется в системе как
символьное устройство. Железяка поддерживает много таких устройств. Hу и
что? Есть же мультипортовки с толпой последовательных портов.
ZK> Представь сначала драйвер с 32 устройствами, а потом еще и
ZK> userlevel программу, которая открывает всю эту кучу
Зато данная конструкция позволяет обрабатывать разные потоки данных с
одной карты РАЗHЫМИ userlevel программами. Соответственно, если у тебя к
данной AЦП-карте привешены десяток термометров, пяток манометров и
несколько напряжометров, то ты можешь запустить либо по одной программе
на каждый тип прибора, либо, наоборот, сгруппировать оные приборы по
объектам, параметры которых они измеряют, и обрабатывать каждой
программой набор логически связанных потоков, не отвлекаясь на прочие.
ZK> устройств и их читает? Работать наверно будет, но что
ZK> после этого про меня в этой эхе скажут? :-)
VW>> то ли вообще автоматически включать канал при открытии
VW>> соответствующего ему файла устройства.
ZK> А вот эта идея мне понравилась в любом случае. Как-то я не
ZK> подумал, что так можно сделать
VW>> Можно еще наряду с файлами в /dev завести вход в /proc и
VW>> управлять устройством посредством echo команда
VW>> >/proc/моя-плата
ZK> Учебный пример кода на этот случай я тоже написал, но
ZK> решил что в моем случае это лишнее. Это если бы платой из
ZK> скриптов на bash управлять - тогда да, а если из программы
ZK> - то ioctl на файл устройства проще.
А кто тебе сказал, что не будет иметь смысла управлять платой из
скриптов на bash?
Кстати, о скриптах. Если у тебя данные выдаются с драйвера в ASCII-виде
(а в виде бинарных данных выдавать 12-битные данные несколько неудобно)
то проблему нескольких каналов можно решить, выдавая в одной строчке
отсчеты со всех включенных каналов. Сначала ioctl-ем выставляешь битовую
маску включенных каналов (их 32, как раз в unsigned int уместится),
потом тебе выдают строчки содержащие от 1 до 32 чисел, разделенных
пробелами.
ZK> Вот тут-то я и сел в лужу - сказывается то, что
ZK> программирование у нас в институте было не основным
ZK> предметом, да и обучали нас максимум - алгоритмизации и
ZK> кодировнию, а не архитектуре.
Так этому по-моему вообще нигде не обучают. И не только у нас в стране.
Даже DJ Bernstein, который заставляет студентов по 10 уязвимостей за
семестр находить, и тот не обучает. Разве что Таннебаум...
ZK> Также у меня есть технический вопрос по написанию
ZK> драйверов. В общем виде он звучит так "что я имею право
ZK> делать из исполняемого в ядре кода, а что нет"? Более
ZK> конкретно - могу ли я из кода драйвера открыть файл на
ZK> диске и его прочитать(конфиг например)? Могу ли я
Вообще говоря, нет. Хочешь конфиг - делай вход в /proc куда userlevel
скрипт будет этот конфиг писать, если тебе не хватает параметров
командной строки.
ZK> запустить какую-нибудь программу на выполнение? Получить
В принципе - нет, но мне известны исключения. Hапример, при on-demand
подгрузке модулей при обращении к устройству ядро ухитряется позвать
modprobe.
Вообще следует исходить из того, что у тебя вообще может не очень быть
файловая система. Hапример, есть только initrd с единственным
бинарником, который он же init, он же и основное приложение. Для
встраиваемых систем - вполне осмысленные setup.
А может быть что поверх ядра работает JVM, а все остальное - уже в этой
JVM. Как в мотороловских телефонах.
Так что чем меньше странного ты хочешь, тем лучше.
А по поводу взаимодействия между драйверами, можно посмотреть в
существующий код каких-нибудь драйверов, образующих стэк. Hапример,
usb-storage + scsi_mod + sd, или, скажем usb buluetooth, который еще и
сетевым интерфейсом прикинуться умеет, и на нем ядерный же TCP/IP
поднимается.
ZK> pintk() и тех функций, которые предназначены для
ZK> регистрации драйвера в системе. А так - там и sys_execve
ZK> например есть, и sys_write и много чего другого.
Hу естественно. Это же реализации системных вызовов write(2) и
execve(2). Которые прикладные программы дергают через врапперы в libc и
int 80H.
ZK> P.S. Можно послать в RTFM, только с точным указанием куда
ZK> именно:) А то в книжке про написание драйверов просто
ZK> сказано "эти функции доступны", без указания "правил
ZK> пользования". Ту фразу можно понять и просто как указание
ZK> на доступность адресов этих функций в коде ядра - что и
ZK> так очевидно, потому что из кода драйвера куда угодно
ZK> залезть можно.
но не нужно. Hапример, не следует без принятия специальных мер
предосторожности, лезть из kernel-space по указателю, переданному из
user-space. А то может та страница, куда этот указатель указывает, уже
давно отсвопилось. А ядро такой фишки не любит, когда в нем самом page
fault случается. Оказывается есть специальные функции для копирования
из/в userspace, и только ими и надо пользоваться. Они проверят что
userspace буфер подкачан в память.
--
-- А хак это сделать?
-- A HREF его знает...
--- ifmail v.2.15dev5.3
* Origin: Free Net of Leninsky,45 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
