Форум по операционной системе GNU/Linux и свободному программному обеспечению
Текущее время: 24 апр 2019, 07:05

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 21 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
Непрочитанное сообщениеДобавлено: 20 фев 2017, 13:14 
Не в сети
Интересующийся

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


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 20 фев 2017, 14:58 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11699
Откуда: Харьков
Kurenya писал(а):
для режима одного прерывания на миллисекунду было бы хорошо передавать данные в приложение без опроса , при этом без потерь информации .
как это сделать ?

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

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

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

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

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

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

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


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 21 фев 2017, 10:10 
Не в сети
Интересующийся

Зарегистрирован: 17 фев 2017, 20:20
Сообщения: 8
Olej писал(а):
Т.е. вы хотите передавать данные из ядра по инициативе ядра (т.е. факически уведомления) периодически, да ещё и с периодом в 1 мс.?
Во-первых, это, скорее всего, плохая идея - трудно придумать даже где-бы мог понадобится такой плотный непрерывный поток информации и что вы потом собираетесь с ним делать. Это самой время задуматься над тем, нет ли где дефекта в самой идее вашей системы или приложения?

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

в этих вариантах сохранность информации не гарантирована .


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 21 фев 2017, 11:37 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11699
Откуда: Харьков
Kurenya писал(а):
полно таких приложений .

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

С какой же это стати "не гарантирована"? ;-)
Вы если такие страшные вещи рассказывайте, то или ссылки показывайте, где такое прочитали ... или соображения свои высказывайте, если чего-то там придумали.

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


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 21 фев 2017, 15:51 
Не в сети
Интересующийся

Зарегистрирован: 17 фев 2017, 20:20
Сообщения: 8
Olej писал(а):
Это неправда ;-)
А если "полно", то покажите хоть несколько (2-3-4) вариантов из этих "полно", чтобы было понятно что вы имеете в виду и хотите
(причём: это не наезд, а это - интерес).

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

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


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 21 фев 2017, 16:29 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11699
Откуда: Харьков
Kurenya писал(а):
Olej писал(а):
Это неправда ;-)
А если "полно", то покажите хоть несколько (2-3-4) вариантов из этих "полно", чтобы было понятно что вы имеете в виду и хотите
(причём: это не наезд, а это - интерес).

управление производством и системы сбора данных научных установок .

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


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 21 фев 2017, 16:42 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11699
Откуда: Харьков
Kurenya писал(а):
вы путаете гарантированную доставку информации пользователю и возможность её восстановления .

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

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

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


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 21 фев 2017, 17:05 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11699
Откуда: Харьков
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, с другой и строго детерминированной дисциплиной планирования, и реализовывайте всё это там.


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 22 фев 2017, 08:35 
Не в сети
Интересующийся

Зарегистрирован: 17 фев 2017, 20:20
Сообщения: 8
Olej писал(а):
...тем более, если модуль это написан в существенной степени "через задницу".
...

всё по ВАШИМ примерам , однако . :lol:

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

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


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 22 фев 2017, 13:32 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11699
Откуда: Харьков
Kurenya писал(а):
будь моя воля с QNX-а я бы и не уходил . ферштейн ? :geek:

QNX кончился, так что его пора забыть.
Kurenya писал(а):
не знаете как сделать - так и скажите

А я вам и сказал, и даже не один вариант.
Просто вы сами не понимаете что вы хотите.


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 21 ]  На страницу Пред.  1, 2, 3  След.

Часовой пояс: UTC + 3 часа


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

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


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB
[ Time : 0.217s | 17 Queries | GZIP : On ]