изменение структуры ядра sk_buff

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

А зачем ты туда что то добавил? :] Тебе не хватает 48 байт в скбуфе на для-разных-нужд?

И это. После такого нововведения надо вообще все модули и собственно ядро пересобрать, что бы оффсеты были актуальными

>кто-нибудь может объяснить, в чем тут дело
пока не увидим лог - нет.

>где можно почитать про то, как надо вносить изменения в структуры ядра?
для начала неплохо бы почитать про особенности разных архитектур (le/be, 32/64 bit, выравнивание, хардварные сетевые компоненты)
но всё равно в большинстве случаев тебе не нужно что-либо менять в структурах ядра.
уж не знаю, что ты там такое гениальное придумал, но без понимания, как устроен sk_buff и как с ним работают различные компоненты, тебе туда лезть нечего.
максимум, что могу посоветовать - сделать структуру
struct sk_buffXXX {
struct sk_buff skb;
твой *указатель;
};
и там, где этот указатель инициализируется - (пере)аллоцировать sk_buffXXX вместо sk_buff и возвращать указатель на skb.
а там, где он используется - преобразовывать переданный sk_buff в sk_buffXXX (всякими container_of) и обращаться к своему указателю.
но и это ЗЛО, хотя и меньшее.

>надо вообще все модули и собственно ядро пересобрать
и udev заодно

спасибо всем, кто ответил

я добавил указатель на свою структуру, которая содержит данные об оригинальном адресе назначения (который я заменяю другим) эти данные мне нужно перебросить в программу пишет вот это(при загрузке ядра): Wating for /dev to be fully populated...udev-work[536]:error changing netif name eth1 to _rename: File exists как ни странно, он НЕ повис в этом месте (то есть, я ошибся а первом посте), надо было просто достаточно долго подождать (обычно это место проскакивает быстро).

после этого система пошла, но случилась следующая странная вещь: у меня есть 3 интерфейса eth0 - на материнке, и 2 одинаковые карточки eth1 и eth2 соответственно. после старта перестала работать eth1 (диоды не горят), но остальные интерфейсы работают нормально. в оригинальном ядре такой ошибки нет. единственное изменение, которое я внес - просто добавил указатель к sk_buff, остальные изменения заккоментировал, чтобы разобраться сначала с этим итак, вопросы: почему сдох один из интерфейсров? почему не сдохли другие?

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

ну я так понимаю, что если я изменяю хедер, то все, кто его включают - пересобираются вряд ли какой-то файл, не включающий skbuff.h каким-то образом зависит от размеров его структур. или я ошибаюсь?

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

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

пересобирать udev я не пробовал. я правильно понимаю, что мне нужно изменять и его код(я так понял, что если он использует sk_buff, то в нем нужно произвести аналогичные изменения)?

я пересобрал udev, и теперь ошибка не выскакивает, все интерфейсы работают, спасибо за совет

и все же, был бы рад услышать о тонкостях внесения изменений в структуры ядра. и какие тут могут быть подводные камни только пожалуйста, не пишите "вносить изменения в структуру ядра НЕЛЬЗЯ" - напишите, почему нельзя.

>я пересобрал udev, и теперь ошибка не выскакивает, все интерфейсы работают, спасибо за совет
Никогда бы не подумал, что причина кроеться здесь.

>"вносить изменения в структуру ядра НЕЛЬЗЯ" - напишите, почему нельзя.
можно, если осторожно)

так.. перезапустил еще несколько раз все оказалось плохо. оказывается, ошибка и правда не зависит от udev, просто она возникает не со 100% вероятностью.

Так ты изменял непосредтвенно заголовочные файлы ядра?!

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

>кроме того, как мне гарантировать, что ее больше никто не использует, кроме меня?
никак. более того, твой указатель в один прекрасный момент может затереться (допустим при перемещении этого буфера в другой участок памяти)

>если я изменяю хедер, то все, кто его включают - пересобираются
ну, не забывай, что кёрнельные хедеры цепляет не только ядро.
тот же glibc...

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

>я добавил указатель на свою структуру, которая содержит данные об оригинальном адресе назначения
а тот, который уже содержится в sk_buff чем не оригинальный?
и да, еще есть такая фигня: sk_buff рассчитан на использование любого протокола, помимо tcp/ip, а ты, получается, нарушаешь эту универсальность.

Ну ты мог погрепать исходники, и найти где и для чего это используют. Например в том же af_packet. Вприцнипе использовать можно :)