Архив форумов ЦИТФорума

[Aragaer]

В Linux.
Пытаюсь написать модуль, который будет выхватывать IP-пакеты, идущие через определенный интерфейс. Соответственно внутри модуля можно работать со структурой sk_buff. Требуется выкинуть ее наружу, чтобы уже другой программой что-то с этим sk_buff'ом делать.
Первая очевидная идея - использовать обычные средства ipc, в частности разделяемую память. Модули не умеют использовать все эти вещи. К сожалению.
Вторая идея - создать устройство, через который выкидывать информацию, а программой соответственно читать. Как выяснилось, символьные устройства для этого непригодны (передать sk_buff как последовательность байтов просто так не получится).
Вопрос: как можно сделать что-то вроде разделяемой памяти, доступной из ядра и из пространства пользователя? Была идея по поводу блочных устройств, но хотелось бы попроще как-нибудь.

Еще один вариант - попробовать превратить sk_buff в последовательный набор байт (то есть по сути обратно в ip-пакет), а потом его разбирать. Насколько реально такое?
_________________
Open your eyes.
And Awaken.

[Ersh]

может ты что-то не так делаешь, но модули тоже умеют работать с шаред мемори...
_________________
Анархия - мать порядка!!!!!!!!!

[benoni]

Используй ф.с /proc, помоему она для этого и предназначена.

[Aragaer]

Получилось с символьным устройством.
Проблема в том, чтобы в пространстве пользователя работать со структурой типа sk_buff - компилятор ругается, что incomplete type, а если подключить linux\skbuff.h, то вылетает огромное количество ошибок в тех библиотеках, которые skbuff.h за собой тянет.
Пересылать структуру iphdr наружу уже получается.
_________________
Open your eyes.
And Awaken.

[pzz]

Нет ничего сложного в том, чтобы использовать skb'шки совместно с character device'ами. Надо только передавать не структуру sk_buff, а ее содержимое.

Буфера, предназначенные для отправки из ядра в user space должны где-то складываться (в ядре, т.е. в драйвере/модуле) в очередь, т.к. появляются они, скорее всего, независимо от желания user space их читать. Чтение должно брать первый буфер из очереди, и копировать его в пользовательский буфер. Если буфер слишком маленький, есть два варианта: либо обрезать данные, либо возвращать ошибку (-EMSGSIZE), чтобы намекнуть user space'у, что неплохо бы предложить буфер побольше. Если чтение произошло без ошибок, буфер удаляется из очереди. Если же при попытке чтения выясняется, что очередь пуста, операция чтения блокируется (т.е., понадобится научиться работать с очередями ожидания, что не сложно).

О чем стоит подумать, это о том, что делать, если SKB'шки для чтения накапливаются, но их никто не читает (например, программа зависла, или ее просто нет). Иначе существует опасность собрать в очереди для чтения всю память ядра, после чего системе, очевидно, придет кирдык

При записи наоборот, SKB'шка аллоцируется, в нее копируются пользовательские данные, и она передается дальше по назначению.

Особой разницы, делать это через /dev или через /proc нету. Это во многом вопрос вкуса. Отмечу одну особенность /dev'а: если devfs не используется, то имя в /dev придется добавить вручную, что не всегда удобно.

Еще одна возможность, раз уж данные внутри ядра представлены SKB'шками, это создать socket, работающий между ядром и userspace. Посмотри в сторону, например, rtnetlink, как это делается.

[Aragaer]

Пришел к выводу, что передавать всю skb'шку мне смысла нет. Даже и весь IP-заголовок не нужен, только saddr. /dev удобнее тем, что в него можно писать, с /proc это (насколько я понял из LKMPG) сложнее.

Но я никак не могу понять, как можно из ядра делать системные вызовы. Те же семафоры мне например понадобились. Понятно, что нужно подключить какую-то библиотеку. Но какую именно?
_________________
Open your eyes.
And Awaken.

[pzz]

В ядре свои семафоры:

struct semaphore sem;

init_MUTEX( &sem );
down( &sem );
up( &sem );

Но вообще, надо бы тебе книжку какую-нибудь найти и почитать.

[Aragaer]

Книжки в гугле искал. Тщательно. Так и не нашел ничего про системные вызовы. То есть нашел про unistd.h, но почему-то не хочет работать.
Еще есть вариант с таблицей системных вызовов. Но в ядре 2.6 это дело спрятано.

Семафорить мне нужно наружу.
То есть снаружи (в пространстве пользователя) некий процесс ожидает смены семафора. Как только это произойдет - читает из нашего символьного устройства.

Хотя, по идее раз мы находимся в режиме ядра, то можно вручную семафоры переключать. В крайнем случае.
А хочется сделать вызов типа sys_semget и не волноваться, что порушу таблицу семафоров.
_________________
Open your eyes.
And Awaken.

[Ersh]

Советую замечательную книжу: "Программирование в Unix" Автор Робачевский.
_________________
Анархия - мать порядка!!!!!!!!!

[pzz]

Не надо ничего семафорить наружу

User space может что-либо вычитать из твоего драйвера только позвав драйверный read. Вот там и синхронизируйся. Будет неплохо также, если твой драйвер будет поддерживать poll/select.

Почитай для начала что-нибудь из этого:

http://www.google.com/search?q=kernel+hacking+guide&sourceid=mozilla&start=0&start=0&ie=utf-8&oe=utf-8

[Aragaer]

Да-да, уже все написал. Сделал блокируемой операцию чтения и все заработало.

Единственное что, так это странный глюк с ERESTARTSYS. А именно: в драйвере

[pzz]

Зачем тебе возвращать ERESTARTSYS? Почему бы тебе не сделать цикл прямо в драйвере?

[Aragaer]

Потому что это более логично.
Дело в том, что в процессе ожидания пользователь может закрыть внешнее приложение. Это тоже прервет ожидание, но это еще не значит, что надо что-то передавать. Такое обрабатывается следующим образом: