Обработка данных между TCP/IP стеком и драйвером

Извини, а для навигации по исходникам чем пользуешься?

какими средствами разработки

find + xargs + grep для навигации xemacs -- для разработки.

Проблемма не в том, что я не могу чег-то найти, а в том, что уже не знаю куда смотреть и что смотреть...

> Далее, по идее, должен вызываться netif_rx из dev.c,

так ведь он и вызывается из pcnet32_rx(), после
skb->protocol=eth_type_trans(skb,dev);

> а  от туда уже ip_rcv.

здесь похитрее. ядро 2.6.

netif_rx() включает NET_RX_SOFTIRQ, дальше работает
softirq (bottom half) handler, net_rx_action().

он вызывает dev->poll(), это поле инициализируется в
net_dev_init(): queue->backlog_dev.poll = process_backlog;

process_backlog() вызывает netif_receive_skb(), которая
смотрит на skb->protocol и находит соответсвующий packet_type{}
из ptype_base[], и вызывает packet_type->func().

а там (в ptype_base), в частности:
struct packet_type ip_packet_type = {
        .type = __constant_htons(ETH_P_IP),
        .func = ip_rcv,
};

о как!

есть сетевой стек. стек не что иное как таблица идентификаторов сответсвующих некоторому набору фунций.

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

ether_input выдергивает нужную ему инфу для работы, в том числе и идентификатор суб-протокола. После всяких проверок и дополнительной конфигурации(например пометить буффер что он пришел через eth0) выдергивается input функция по идентификатору суб-протоколу, буффер пакета кастрируется(обрубается верхний хидер[в нашем случае ethernet]) и отдается в input фунцию.

в твоем случае суб-протокола это IP - и input фунция для него это ну я не знаю - ip_rcv или ip_input ..

ip_input в свою очередь проделает тоже самое тоько пользовать будет интернет стек для выбора следуещего input метода ..

так будет происходить до тех пор пока данные не вылезут на application level

да кстати, так как из интерупта лучше сразу вылазить, драйвер(или generic обвязка) сетевухи может шедулить пакет на обработку и побыстренькому возвратить, и реальная обработка пакета произойдет попозже

PS: нафига пользавать grep, xargs, find в консоли .. если у тебя в руках такая мощь как xemacs? ..

Товарищи, откуда вы так разбираетесь в ядре? Где и что читаете?
Подскажите плизззззззз!

> Где и что читаете?

да исходники и читаем, и ничем этого не заменить.

ядро - это всего лишь программа, просто большая.
ничего там таинственного нету, но и рассчитывать,
что это можно "выучить за ночь", как в математике,
не стоит.

лично я из книжек читал только Баха (не помню, как
называется, что-то про Unix, есть в сети), и всем
его рекомендую, даже тем, кто вообще программировать
не собирается. хотя этой книжке лет 20, наверное.

у меня есть Linux Device Drivers (есть в сети), и
Understanding the Linux Kernel. но попали они ко мне
поздно, я их не читал. тем не менее, первая мне кажется
очень толковой, может с нее и стоит начинать.

но без чтения исходников это будет - имхо - "для общего
развития", ибо devil in the details.

ага - основной подход это смотреть как это реально делают в реальных ядрах.

из книжек Бах клево для начала, кстати у меня даже лежит эта книжка .. http://lgarc.narod.ru/doc/unix

еще хорошая книжка Столинга, "Операционные сыстемы"

книжки хороши чтобы создать некую абстракцию о том какой дезайн у вещей(кстати у Столлинга рассматриваются некоторые концепты которые еще даже не заимплеменчены нигде) - то есть некий теоретический костяк и общее представление о том как все выглядит, получается некий такой скелет знаний .. потом читая исходники ты на этот скелет наращиваешь мыжцу .. и становишься таким как idle :)))

[off]

Сетевая часть Linux не очень модульна...
в отличие от Win/WDM или UNIX/STREAMS.

Rusty Russel был отчасти прав, когда писал
про "bad vodka". :)

[/off]

> Rusty Russel был отчасти прав, когда писал
> про "bad vodka". :)

а ты бы привел цитату, а то заинтриговал, и бросил...

любопытна! а работать неееехоооочееется...

idle:

Ну как же. :)
cd /usr/src/linux/Documentation
find . -exec grep -H vodka {} \;

> find . -exec grep -H vodka {} \;

эх, всеж-таки, и наша страна вносит вклад в современную
культуру. они нам - файл, а мы им в ответ - vodka!

idle, Большое спасибо! Разобрался.

В 2.4 отличае в том, что вызов packet_type->func происходит сразу net_rx_action, а инициализация этой структуры ip_rcv происходит в ip_output.c ip_init() (несколько раз уже путался что является входом, а что выходом для tcp/ip стека и драйверов).

В 2.2 устанавливается в netif_rx bottom half NET_BH на net_bh -- там и производится вызов packet_type->func. Инициализация такая же, как и 2.4

> В 2.4 отличае в том, что вызов packet_type->func происходит
> сразу net_rx_action

в таком случае, у вас какая-то древняя версия ядра 2.4,
я бы рекомендовал обновить. какой смысл изучать то, что
сильно устарело?