Работа с ком-портом из модуля

Зачем тебе нужно делать это именно из модуля ядра?

>Не понимаю как открыть файл, например, /dev/ttyS0 чтоб туда писАть и читать

На прямую из модуля ядра?!

mknod /tmp/ttyS0 c 4 64

Необходимо общаться с девайсом, который ведет время, мониторит напряжения и т.д. Поэтому я хотел сделать модуль, который загружается с ядром, получает запрос от "синхронизатора времени" drivers/rtc/hctosys.c , отправляет модбас запрос в девайс на получение текущего времени, отдает полученное время наверх. Потом с некоторым интервалом выводит в /proc/sv/info инфу о напряжениях и т.д. По записи из юзерленда в какой-либо файл, например, /proc/sv/test надо послать запрос на выполнение теста. Поэтому подумал, что модуль больше подходит, может и не прав.

>mknod /tmp/ttyS0 c 4 64

arsi, не совсем понял где и когда надо это выполнить? И потом можно будет делать sys_open("/tmp/ttyS0") ?

зачем тащить в ядро то, что легко и непринужденно делается в юзерлэнде?

>На прямую из модуля ядра?!

Ну может не совсем правильно написал. Из потока, который я создал при вызове функции инициализации модуля.

А за какие грехи заставляют это в ядре делать?

автор, а почему именно в ядро пыташься запихать свой велосипед ?

поясни если не сложно.

>зачем тащить в ядро то, что легко и непринужденно делается в юзерлэнде?

Подскажите как установить системное время при старте системы? Я так понимаю, что пока юзерленд прога не запустится время будет 00:00 ?

Какое системное время? Которое из набортных часов берётся?

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

:) Много чего не знаю. Считал, что в ядре будет легче. Как, например, полученные из девайса координаты тачскрина передать в систему, чтоб потом любая прога могла открыть /dev/event0 и получать события? Примеры в ядре нашел, а как в юзерленде делать не пойму.

>Какое системное время? Которое из набортных часов берётся?

Да, девайс ведет время, дату и арм при старте его должен спросить.

ха, так вам из кернелспейса надобно… но тут вылазит явная проблема: даже если вы обратитесь непосредственно к драйверу ком-порта, далеко не факт, то он к тому времени успеет проинициализироваться. как вариант: можете в том же /proc создать переменную, в которую через echo "/dev/ttyS0" > /proc/…/tty_device в инициализационном скрипте, выполняемом после запуска udev, можно было бы передать путь к файлу устройства.

> Подскажите как установить системное время при старте системы?

clock_settime + CLOCK_REALTIME

> Я так понимаю, что пока юзерленд прога не запустится время будет 00:00 ?

Если на твоей плате нет автономных часов (а насколько я понял, так оно и есть), то да. Ещё будет первое января 1970-го года =).

>но тут вылазит явная проблема: даже если вы обратитесь непосредственно к драйверу ком-порта, далеко не факт, то он к тому времени успеет проинициализироваться.

arsi, ну если смотреть по логу загрузки, то я вижу, что сначала создаются девайсы ком-портов, потом загружается мой модуль, но /dev/ttyS0 еще нет, поскольку не выполнился udev. В исходниках ядра есть функции типа class_find_device и подобные, которые по имени ком-порта могут вернуть struct device *, только что с ним делать дальше я не понимаю. Как добраться до функций открытия, чтения, записи? А могу я создать статический файл /dev/ttyS0 и обращаться к нему не дожидаясь udev? При инициализации ком-порта драйвер свяжется с этим файлом?

>> Подскажите как установить системное время при старте системы?

>clock_settime + CLOCK_REALTIME

Т.е. это делает юзерленд прога, которая получила время от девайса. Но пользователи используют hwclock и если не делать модуль, который использует RTC интерфейс, то надо будет для пользователей делать другую прогу с помощью которой они будут менять время, так?

> Т.е. это делает юзерленд прога, которая получила время от девайса.

Да.

> Но пользователи используют hwclock и если не делать модуль, который использует RTC интерфейс, то надо будет для пользователей делать другую прогу с помощью которой они будут менять время, так?

Зачем пользователи используют hwclock? Ты случаем не путаешь аппаратные часы и программные?

>Как добраться до функций открытия, чтения, записи?

Почитай про VFS

Или ты хочешь написать собственный драйвер RTC, который будет брать время с девайса на компорте?

> А могу я создать статический файл /dev/ttyS0 и обращаться к нему не дожидаясь udev?

естественно.

> При инициализации ком-порта драйвер свяжется с этим файлом?

наоборот)

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

# hdparm /dev/sda
…
# mknod /tmp/1234 b 8 0
# hdparm /tmp/1234
…

> Или ты хочешь написать собственный драйвер RTC, который будет брать время с девайса на компорте?

Если это действительно так... поверхностный гуглинг показывает, что для того что ты хочешь, можно использовать inb_p() и outb_p() и напрямую работать с портом, минуя модуль ядра для /dev/ttyS*.

>Зачем пользователи используют hwclock? Ты случаем не путаешь аппаратные часы и программные?

Ну когда батарейку меняешь на контроллере, потом надо время как то установить, вроде hwclock какраз для этой цели.

>> Или ты хочешь написать собственный драйвер RTC, который будет брать время с девайса на компорте?

Именно так. Просто девайс на компорте может много чего давать и брать. Вот я и подумал, что будет набор драйверов RTC, тачскрин и т.д. и все они общаются через один компорт по модбасу.

>Если это действительно так... поверхностный гуглинг показывает, что для того что ты хочешь, можно использовать inb_p() и outb_p() и напрямую работать с портом, минуя модуль ядра для /dev/ttyS*.

Можно, только получается всё самому делать надо, скорость настраивать, ошибки обрабатывать. Ну и вроде не портируемый код получится совсем. sys_read sys_write поприличнее выглядят, имхо.

>ядру сам этот файл до лампочки. ему нужны только мажор/минор и тип устройства, чтобы связать дескриптор файла с драйвером.

Хм, если я знаю мажор\минор номера устройства и тип, я могу открыть файл не указывая имя? Если да, то какая функция в ядре это делает?

посмотрите здесь: /usr/src/linux/drivers/input/touchscreen/penmount.c

достаточно маленький драйвер сенсорного экрана, принимающий через последовательный порт и вещающий через /dev/input/event*.

Ты собрался ядрёный модуль линковать с модбас сервером? Мистер знает толк в извращениях. ИМХО лучше сделай обычную юзер-спэйс программу.

>посмотрите здесь: /usr/src/linux/drivers/input/touchscreen/penmount.c

>достаточно маленький драйвер сенсорного экрана, принимающий через последовательный порт и вещающий через /dev/input/event*.

Если не ошибаюсь, то интерфейс serio только на ввод работает.

>Ты собрался ядрёный модуль линковать с модбас сервером? Мистер знает толк в извращениях. ИМХО лучше сделай обычную юзер-спэйс программу.

Я думал реализовать пару модбас функций мастера (read hold reg, preset multiple regs). Больше мне и не надо.

> Если не ошибаюсь, то интерфейс serio только на ввод работает.

/usr/src/linux/drivers/input/touchscreen/elo.c

F7 | Ctrl-F → serio_write

> /usr/src/linux/drivers/input/touchscreen/elo.c

> F7 | Ctrl-F → serio_write

Да, действительно запись есть :) Поглядел я на эти драйверы и похоже, что всё что связано с serio нуждается в утилите inputattach, которая подключит нужный компорт к подсистеме ввода.