драйвер , обновление информации

Вопросы программного кода и архитектуры Linux

Модератор: Olej

Kurenya
Интересующийся
Сообщения: 8
Зарегистрирован: 17 фев 2017, 20:20
Контактная информация:

Re: драйвер , обновление информации

Непрочитанное сообщение Kurenya » 20 фев 2017, 13:14

ещё один вопрос : для режима одного прерывания на миллисекунду было бы хорошо передавать данные в приложение без опроса , при этом без потерь информации .
как это сделать ?

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: драйвер , обновление информации

Непрочитанное сообщение Olej » 20 фев 2017, 14:58

Kurenya писал(а):для режима одного прерывания на миллисекунду было бы хорошо передавать данные в приложение без опроса , при этом без потерь информации .
как это сделать ?
Т.е. вы хотите передавать данные из ядра по инициативе ядра (т.е. факически уведомления) периодически, да ещё и с периодом в 1 мс.?

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

Во-вторых, обычно если нужно какое-то взаимодействие приложения пользовательского пространства и ядра, то происходит оно по инициативе приложения, не ядра (не барское это дело ;-) ). На такую философию ориентированы и все механизмы и API модулей ядра Linux.

Но если вам прямо категорически хочется именно так, то это можно сделать и даже несколькими (многими) способами, как это обычно и бывает:

1. Ядро по событию (прерыванию) может посылать сигнал UNIX приложению (типа SIGUSR1). Для того, чтобы знать какому процессу направлять сигнал, процесс этот должен бы при старте каким-то образом зарегистироваться (в модуле ядра). Такой пример, в полном виде, приведен в коде архивов моей книге (и описан в тексте ... глава "Сигналы").
И вскользь обсуждается здесь: Как общаться с++ приложению с модулями или с хидерам ядра.

2. Ядро по событию (прерыванию) может посылать широковещательную дэйтаграмму UDP-сокета специального вида NETLINK. На этом принципе работает вся подсистема udev. Это обсуждалось здесь в форуме:
Проблема с отправкой sk_buff->data в netlink пользователю
асинхронные уведомления и udev
В последней теме есть готовые примеры работающего кода.
Ваше отдельное "приёмное" приложение может ловить такие UDP-дэйтаграммы.
Или можете на них прописать реакцию правилами /etc/udev/rules.d

Вариантов множество!

Kurenya
Интересующийся
Сообщения: 8
Зарегистрирован: 17 фев 2017, 20:20
Контактная информация:

Re: драйвер , обновление информации

Непрочитанное сообщение Kurenya » 21 фев 2017, 10:10

Olej писал(а): Т.е. вы хотите передавать данные из ядра по инициативе ядра (т.е. факически уведомления) периодически, да ещё и с периодом в 1 мс.?
Во-первых, это, скорее всего, плохая идея - трудно придумать даже где-бы мог понадобится такой плотный непрерывный поток информации и что вы потом собираетесь с ним делать. Это самой время задуматься над тем, нет ли где дефекта в самой идее вашей системы или приложения?
полно таких приложений .
Olej писал(а): Во-вторых, обычно если нужно какое-то взаимодействие приложения пользовательского пространства и ядра, то происходит оно по инициативе приложения, не ядра (не барское это дело ;-) ). На такую философию ориентированы и все механизмы и API модулей ядра Linux.
Но если вам прямо категорически хочется именно так, то это можно сделать и даже несколькими (многими) способами, как это обычно и бывает:
1. Ядро по событию (прерыванию) может посылать сигнал UNIX приложению (типа SIGUSR1). Для того, чтобы знать какому процессу направлять сигнал, процесс этот должен бы при старте каким-то образом зарегистироваться (в модуле ядра). Такой пример, в полном виде, приведен в коде архивов моей книге (и описан в тексте ... глава "Сигналы").
И вскользь обсуждается здесь: Как общаться с++ приложению с модулями или с хидерам ядра.
2. Ядро по событию (прерыванию) может посылать широковещательную дэйтаграмму UDP-сокета специального вида NETLINK. На этом принципе работает вся подсистема udev. Это обсуждалось здесь в форуме:
Проблема с отправкой sk_buff->data в netlink пользователю
асинхронные уведомления и udev
В последней теме есть готовые примеры работающего кода.
Ваше отдельное "приёмное" приложение может ловить такие UDP-дэйтаграммы.
Или можете на них прописать реакцию правилами /etc/udev/rules.d
Вариантов множество!
в этих вариантах сохранность информации не гарантирована .

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: драйвер , обновление информации

Непрочитанное сообщение Olej » 21 фев 2017, 11:37

Kurenya писал(а): полно таких приложений .
Это неправда ;-)
А если "полно", то покажите хоть несколько (2-3-4) вариантов из этих "полно", чтобы было понятно что вы имеете в виду и хотите
(причём: это не наезд, а это - интерес).
Kurenya писал(а): в этих вариантах сохранность информации не гарантирована .
С какой же это стати "не гарантирована"? ;-)
Вы если такие страшные вещи рассказывайте, то или ссылки показывайте, где такое прочитали ... или соображения свои высказывайте, если чего-то там придумали.

P.S. На 2-м из названных способов (NETLINK) базируется вся подсистема управления устройствами в современном Linux (раньше это было не так): горячие подключения устройств, вся файловая системы /sys, подсистема udev ... и, в конечном итоге, вся традиционная система /dev, которая на сегодня работает через /sys и udev. Рассмотрите каталог /dev в незагруженной системе (LiveCD или инсталляции на другом разделе диска) - и вы там ничего не увидите, всё это создаётся динамически с помощью NETLINK!
А тут вдруг - "не гарантирована" :-o

Kurenya
Интересующийся
Сообщения: 8
Зарегистрирован: 17 фев 2017, 20:20
Контактная информация:

Re: драйвер , обновление информации

Непрочитанное сообщение Kurenya » 21 фев 2017, 15:51

Olej писал(а): Это неправда ;-)
А если "полно", то покажите хоть несколько (2-3-4) вариантов из этих "полно", чтобы было понятно что вы имеете в виду и хотите
(причём: это не наезд, а это - интерес).
управление производством и системы сбора данных научных установок .
Olej писал(а): С какой же это стати "не гарантирована"? ;-)
Вы если такие страшные вещи рассказывайте, то или ссылки показывайте, где такое прочитали ... или соображения свои высказывайте, если чего-то там придумали.
P.S. На 2-м из названных способов (NETLINK) базируется вся подсистема управления устройствами в современном Linux (раньше это было не так): горячие подключения устройств, вся файловая системы /sys, подсистема udev ... и, в конечном итоге, вся традиционная система /dev, которая на сегодня работает через /sys и udev. Рассмотрите каталог /dev в незагруженной системе (LiveCD или инсталляции на другом разделе диска) - и вы там ничего не увидите, всё это создаётся динамически с помощью NETLINK!
А тут вдруг - "не гарантирована" :-o
вы путаете гарантированную доставку информации пользователю и возможность её восстановления .
если чтение /dev прошло с ошибкой , то какое-то последующее чтение пройдёт нормально с высокой вероятностью и ни системе , ни компу плохо от этого не будет .
а вот если потеряется информация с какого-нибудь датчика , то будут неприятности .

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: драйвер , обновление информации

Непрочитанное сообщение Olej » 21 фев 2017, 16:29

Kurenya писал(а):
Olej писал(а): Это неправда ;-)
А если "полно", то покажите хоть несколько (2-3-4) вариантов из этих "полно", чтобы было понятно что вы имеете в виду и хотите
(причём: это не наезд, а это - интерес).
управление производством и системы сбора данных научных установок .
Это уже пошёл уровень разговора: бла-бла-бла ... при такой детальности утверждений...
Я не один десяток лет работал в разработке проектов и "управление производством" и "систем сбора данных".
Но я попросил обсудить конкретно в технических терминах архитектуру программных систем (на примерах), где ядро операционной системы Linux (конкретно этой) по своей инициативе (без запросов со стороны приложений пользовательского пространства) создавало бы поток уведомлений или данных, с плотностью во времени 1 поступления событие в миллисекунду. Это чрезвычайно высокая плотность даже для ядра операционной системы, если мы вспомним константу ядра HZ=1000, которая указывает на то, что минимальным маркером, шагом изменения состояний системного времени в операционной системе является 1 миллисекунда.
И я утверждаю, что систем с такой архитектурой практически нет, или есть, но в совершенно исключительных случаях, для каких-то особо специальных условий.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: драйвер , обновление информации

Непрочитанное сообщение Olej » 21 фев 2017, 16:42

Kurenya писал(а): вы путаете гарантированную доставку информации пользователю и возможность её восстановления .
Я абсолютено ничего не путаю.
Это вы норовите смешать в кучу зелёное с горячим...
Kurenya писал(а): если чтение /dev прошло с ошибкой , то какое-то последующее чтение пройдёт нормально с высокой вероятностью и ни системе , ни компу плохо от этого не будет .
а вот если потеряется информация с какого-нибудь датчика , то будут неприятности .
С какого ляду она потеряется?
Чем данные, считанные с /dev, /proc, /sys будут более достоверные, чем переданные в уведомлении?
Асинхронные уведомления - более надёжный механизм, чем даже синхронное чтение из вашего модуля ядра ... тем более, если модуль это написан в существенной степени "через задницу".

И вообще, есть неукоснительное правило: чем большая часть функциональности проекта вынесена из адресного пространства ядра в адресное пространство пользователя - тем выше надёжность и живучесть системы, и меньше причин и вероятностей искажений или потерь данных.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: драйвер , обновление информации

Непрочитанное сообщение Olej » 21 фев 2017, 17:05

Kurenya писал(а): вы путаете гарантированную доставку информации пользователю и возможность её восстановления .
если чтение /dev прошло с ошибкой , то какое-то последующее чтение пройдёт нормально с высокой вероятностью и ни системе , ни компу плохо от этого не будет .
а вот если потеряется информация с какого-нибудь датчика , то будут неприятности .
Или вы решили, что если после ошибки чтения из /dev начнёте повторно долбить раз за разом такое же чтение, то вы из него, в конечном итоге, из него выдолбите сокровенные данные?
Ерунда! Ошибку чтения только вы сами можете сообщить из кода, и возникает она, как правило, из-за некорректности вашего же собственного обрабатывающего кода. С какой же стати 2-е, 5-е, или 155-е повторение той же ошибочной ситуаций в том же окружении "продолбит" в конце-концов ситуацию?

И, тем более, обратите ещё внимание на то, что в многозадачной среде ваше пользовательское приложение, выполняющее циклический опрос типа:

Код: Выделить всё

while( 1 ) {
  ...
  fread(str,len,1,dfd);
  fseek(dfd,0,SEEK_SET);
  usleep(100000);
  ...
  };
- никогда не будет гарантировано считывать ваши данные строго через 1 миллисекунду (за счёт вытеснения), каждая из этих 3-х операций - блокирующая, на которой вы можете иметь задержки сколь угодно больше предполагаемых (и это совершенно корректно и совпадает с требованиями real-time как они формулируются POSIX 1003b). Так что в этом случае у вас могут быть любые пропуски и потери данных.

А если у вас такая critical missian задача, что пропуск 1-го миллисекундного отсчёта сразу вызовет Армагедон, то вам ОС Linux принципиально не годится.
Тогда покупайте строго realtime OS QNX, с другой и строго детерминированной дисциплиной планирования, и реализовывайте всё это там.

Kurenya
Интересующийся
Сообщения: 8
Зарегистрирован: 17 фев 2017, 20:20
Контактная информация:

Re: драйвер , обновление информации

Непрочитанное сообщение Kurenya » 22 фев 2017, 08:35

Olej писал(а): ...тем более, если модуль это написан в существенной степени "через задницу".
...
всё по ВАШИМ примерам , однако . :lol:

будь моя воля с QNX-а я бы и не уходил . ферштейн ? :geek:

не знаете как сделать - так и скажите , а пальцы гнуть , да ещё в таком тоне , лучше в другом месте . :evil:

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: драйвер , обновление информации

Непрочитанное сообщение Olej » 22 фев 2017, 13:32

Kurenya писал(а): будь моя воля с QNX-а я бы и не уходил . ферштейн ? :geek:
QNX кончился, так что его пора забыть.
Kurenya писал(а): не знаете как сделать - так и скажите
А я вам и сказал, и даже не один вариант.
Просто вы сами не понимаете что вы хотите.

Ответить

Вернуться в «Linux изнутри»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 4 гостя