форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

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

Сообщение от freem4n (??) on 03-Окт-07, 15:20

Всем доброго времени суток. Какой интерфейс обмена выбрать? Можно ли использовать обычные интерфейсы IPC?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

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

Сообщение от BigHo on 03-Окт-07, 16:07

>Всем доброго времени суток. Какой интерфейс обмена выбрать? Можно ли использовать обычные >интерфейсы IPC? Вы наверное не очень ожидаете ответ, если практически ничего не рассказали о том, что это за интерфейс, что за ОС, и про массу других вещей, о которых не стоило упоминать вследствии развитой телепатии у большинства людей. Также создалось впечатление, что не стоило быть столь категорическим во фразе "интерфейс передачи данных от ядра к процессу", если в качестве этого предлагается применять IPC (Inter Process Communications). -- На экзамене: - Вы прочитали "Три сестры" ? А теперь расскажите нам про героинь.. - Героин - сильная вещь. А вам это зачем ?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

	3. "Выбор интерфейса передачи данных от ядра к процессу и обратн..."
	Сообщение от BigHo on 03-Окт-07, 19:20
	>Бля, про ОС действительно запамятовал, но подразумевался Linux. Про какие массы еще >рассказать? Косяк, сори :) Детальное описание преследуемой цели иногда интересней для рассмотрения, чем пресловутый пятновыводитель в виде "интерфейса передачи данных от ядра к процессу". Чем интересней вопрос, тем больше найдется любителей головоломок, иногда даже грамотных :) Наводящий вопрос: из темы сообщения следует, что вы собрались создать некий поток для общения пользовательской программы с модулем ядра. Но поскольку сюда каким то образом затесалось взаимодействие процессов (IPC), получаем противоречие. P.S. по всей видимости это либо шутка, либо что то другое.. Ммм.. конопляное курево ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Выбор интерфейса передачи данных от ядра к процессу и обратн..."
	Сообщение от freem4n (??) on 04-Окт-07, 08:16
	Хочется постебаться, идите на баш. Надеюсь так будет достаточно детально. Да действительно есть модуль ядра и процесс. Нужно организовать обмен данными между ними. Прошу помочь выбрать интерфейс. Ядро 2.6. P.S. Нет, не курил. А у вас есть че?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Выбор интерфейса передачи данных от ядра к процессу и обратн..."
	Сообщение от anonymous (??) on 04-Окт-07, 10:11
	>Надеюсь так будет достаточно детально. >Да действительно есть модуль ядра и процесс. Нужно организовать обмен данными между >ними. Прошу помочь выбрать интерфейс. Ядро 2.6. Без описания задачи невозможно посоветовать что-то конкретное.  Одним подойдёт ioctl(), другим будет лучше создавать файлы в /proc и т. д.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Выбор интерфейса передачи данных от ядра к процессу и обратн..."
	Сообщение от freem4n (??) on 04-Окт-07, 10:49
	Есть устройство, висит на системной шине, под него пишем драйвер. Поток информации очень большой (макс. 40 Мб/с, средн. 16 Мб/с). В идеале нам подходит fifo. Можно ли пользовать fifo из ядра? Если можно то схема работы будет следующая: 1. реализовать простой протокол для обмена данными между драйвером и программой 2. программа создает fifo 3. драйвер подключается к каналу и начинает гнать данные с устройства 4. управление устройством посредством драйвера через ioctl Если есть какие-либо идеи, поправки, то буду рад выслушать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

	8. "Выбор интерфейса передачи данных от ядра к процессу и обратн..."
	Сообщение от freem4n (??) on 04-Окт-07, 15:11
	>Зачем фифо? Чем обычный символьный девайс не подойдет? Объем информации большой и скорее всего программа будет не успевать за девайсом. Т.е. в программе придется делать буферизацию, лишний код и время. В случае fifo драйвер будет постоянно его забивать, а программа уже будет обрабатывать тогда когда есть возможность. Тем паче поток не постоянный. Есть еще интерфейс netlink, но возникает вопрос, не будет ли  обрабатываться стек TCP/IP при приеме/передачи и я уверен, что fifo быстрее чем netlink.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Выбор интерфейса передачи данных от ядра к процессу и обратн..."
	Сообщение от pavel_simple (ok) on 04-Окт-07, 15:39
	уверен, что fifo быстрее чем >netlink. могу ошибаться но ralayfs насколько я помню придумана специально для целей передачи большиш объёмов данных из kernel в userspace http://www.opersys.com/relayfs/ http://en.wikipedia.org/wiki/Relayfs http://relayfs.sourceforge.net/ примеры присутствуют
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

	11. "Выбор интерфейса передачи данных от ядра к процессу и обратн..."
	Сообщение от pavel_simple (ok) on 05-Окт-07, 07:02
	>Да, действительно, relayfs предназначена для этого, благодарю за ответ. Но все же >не совсем то: >1. Система встраиваемая, ядро переработанное, поэтому функционала relayfs нет. >2. У девайса банк памяти равен 2 Мб, т.е. максимальный объем данных, >передаваемых с девайса         >  за один раз, будет равен именно 2 Мб. > >Интересен именно fifo. думаю char device в данном случае будет самое оно -- по fifo не подскажу НО -- недавно пробегала статья на счёт сокетов -- оно конечно не одно и тоже -- хотя.... я насколько понял fifo нужен из-за необходимости кэшировать в памяти данные от девайса -- так вот -- такая тема всё равно не протянет -- буферы и их работу всё равно писать придётся -- если не в userspace -- то в kernel -- что как мне понимается не есть верный подход.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Выбор интерфейса передачи данных от ядра к процессу и обратн..."
	Сообщение от freem4n (??) on 05-Окт-07, 09:08
	Будем пробовать. Всем спасибо.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]