URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID9
Нить номер: 6806
[ Назад ]

Исходное сообщение
"Выбор интерфейса передачи данных от ядра к процессу и обратно"

Отправлено freem4n , 03-Окт-07 15:20 
Всем доброго времени суток. Какой интерфейс обмена выбрать? Можно ли использовать обычные интерфейсы IPC?

Содержание

Сообщения в этом обсуждении
"Выбор интерфейса передачи данных от ядра к процессу и обратн..."
Отправлено BigHo , 03-Окт-07 16:07 
>Всем доброго времени суток. Какой интерфейс обмена выбрать? Можно ли использовать обычные
>интерфейсы IPC?

Вы наверное не очень ожидаете ответ, если практически ничего не рассказали о том, что это за интерфейс, что за ОС, и про массу других вещей, о которых не стоило упоминать вследствии развитой телепатии у большинства людей.

Также создалось впечатление, что не стоило быть столь категорическим во фразе "интерфейс передачи данных от ядра к процессу", если в качестве этого предлагается применять IPC (Inter Process Communications).

--
На экзамене:
- Вы прочитали "Три сестры" ? А теперь расскажите нам про героинь..
- Героин - сильная вещь. А вам это зачем ?


"Выбор интерфейса передачи данных от ядра к процессу и обратн..."
Отправлено freem4n , 03-Окт-07 17:23 
Бля, про ОС действительно запамятовал, но подразумевался Linux. Про какие массы еще рассказать? Косяк, сори :)


"Выбор интерфейса передачи данных от ядра к процессу и обратн..."
Отправлено BigHo , 03-Окт-07 19:20 
>Бля, про ОС действительно запамятовал, но подразумевался Linux. Про какие массы еще
>рассказать? Косяк, сори :)

Детальное описание преследуемой цели иногда интересней для рассмотрения, чем пресловутый пятновыводитель в виде "интерфейса передачи данных от ядра к процессу". Чем интересней вопрос, тем больше найдется любителей головоломок, иногда даже грамотных :)

Наводящий вопрос: из темы сообщения следует, что вы собрались создать некий поток для общения пользовательской программы с модулем ядра. Но поскольку сюда каким то образом затесалось взаимодействие процессов (IPC), получаем противоречие.

P.S. по всей видимости это либо шутка, либо что то другое.. Ммм.. конопляное курево ?


"Выбор интерфейса передачи данных от ядра к процессу и обратн..."
Отправлено freem4n , 04-Окт-07 08:16 
Хочется постебаться, идите на баш.

Надеюсь так будет достаточно детально.
Да действительно есть модуль ядра и процесс. Нужно организовать обмен данными между ними. Прошу помочь выбрать интерфейс. Ядро 2.6.

P.S. Нет, не курил. А у вас есть че?


"Выбор интерфейса передачи данных от ядра к процессу и обратн..."
Отправлено anonymous , 04-Окт-07 10:11 
>Надеюсь так будет достаточно детально.
>Да действительно есть модуль ядра и процесс. Нужно организовать обмен данными между
>ними. Прошу помочь выбрать интерфейс. Ядро 2.6.

Без описания задачи невозможно посоветовать что-то конкретное.  Одним подойдёт ioctl(), другим будет лучше создавать файлы в /proc и т. д.


"Выбор интерфейса передачи данных от ядра к процессу и обратн..."
Отправлено freem4n , 04-Окт-07 10:49 
Есть устройство, висит на системной шине, под него пишем драйвер. Поток информации очень большой (макс. 40 Мб/с, средн. 16 Мб/с). В идеале нам подходит fifo. Можно ли пользовать fifo из ядра?

Если можно то схема работы будет следующая:

1. реализовать простой протокол для обмена данными между драйвером и программой
2. программа создает fifo
3. драйвер подключается к каналу и начинает гнать данные с устройства
4. управление устройством посредством драйвера через ioctl

Если есть какие-либо идеи, поправки, то буду рад выслушать.


"Выбор интерфейса передачи данных от ядра к процессу и обратн..."
Отправлено Forth , 04-Окт-07 13:02 
>[оверквотинг удален]
>подходит fifo. Можно ли пользовать fifo из ядра?
>
>Если можно то схема работы будет следующая:
>
>1. реализовать простой протокол для обмена данными между драйвером и программой
>2. программа создает fifo
>3. драйвер подключается к каналу и начинает гнать данные с устройства
>4. управление устройством посредством драйвера через ioctl
>
>Если есть какие-либо идеи, поправки, то буду рад выслушать.

Зачем фифо? Чем обычный символьный девайс не подойдет?


"Выбор интерфейса передачи данных от ядра к процессу и обратн..."
Отправлено freem4n , 04-Окт-07 15:11 
>Зачем фифо? Чем обычный символьный девайс не подойдет?

Объем информации большой и скорее всего программа будет не успевать за девайсом. Т.е. в программе придется делать буферизацию, лишний код и время. В случае fifo драйвер будет постоянно его забивать, а программа уже будет обрабатывать тогда когда есть возможность. Тем паче поток не постоянный. Есть еще интерфейс netlink, но возникает вопрос, не будет ли  обрабатываться стек TCP/IP при приеме/передачи и я уверен, что fifo быстрее чем netlink.


"Выбор интерфейса передачи данных от ядра к процессу и обратн..."
Отправлено pavel_simple , 04-Окт-07 15:39 
уверен, что fifo быстрее чем
>netlink.

могу ошибаться но ralayfs насколько я помню придумана специально для целей передачи большиш объёмов данных из kernel в userspace

http://www.opersys.com/relayfs/
http://en.wikipedia.org/wiki/Relayfs
http://relayfs.sourceforge.net/
примеры присутствуют


"Выбор интерфейса передачи данных от ядра к процессу и обратн..."
Отправлено freem4n , 04-Окт-07 16:22 
Да, действительно, relayfs предназначена для этого, благодарю за ответ. Но все же не совсем то:
1. Система встраиваемая, ядро переработанное, поэтому функционала relayfs нет.
2. У девайса банк памяти равен 2 Мб, т.е. максимальный объем данных, передаваемых с девайса           за один раз, будет равен именно 2 Мб.

Интересен именно fifo.



"Выбор интерфейса передачи данных от ядра к процессу и обратн..."
Отправлено pavel_simple , 05-Окт-07 07:02 
>Да, действительно, relayfs предназначена для этого, благодарю за ответ. Но все же
>не совсем то:
>1. Система встраиваемая, ядро переработанное, поэтому функционала relayfs нет.
>2. У девайса банк памяти равен 2 Мб, т.е. максимальный объем данных,
>передаваемых с девайса        
>  за один раз, будет равен именно 2 Мб.
>
>Интересен именно fifo.

думаю char device в данном случае будет самое оно -- по fifo не подскажу НО -- недавно пробегала статья на счёт сокетов -- оно конечно не одно и тоже -- хотя....
я насколько понял fifo нужен из-за необходимости кэшировать в памяти данные от девайса -- так вот -- такая тема всё равно не протянет -- буферы и их работу всё равно писать придётся -- если не в userspace -- то в kernel -- что как мне понимается не есть верный подход.


"Выбор интерфейса передачи данных от ядра к процессу и обратн..."
Отправлено freem4n , 05-Окт-07 09:08 
Будем пробовать. Всем спасибо.