Здравствуйте, so5team, Вы писали:

S>Здравствуйте, lpd, Вы писали:

S>что будет, если мне потребуется вместо skb_rbtree_walk_from(skb) написать skb_rbtree_walk_from(skb+1)?

Ты наверное понимаешь, что skb — указатель, и (skb+1) в данном случае смысла не имеет.
Будет просто skb_rbtree_walk_from(skb_rb_next(skb)). Так что непонятно в чем твоя претензия в данном случае.

S>Полагаю, разбираться в чужих макросах сильно проще, чем в чужих шаблонах.

Макросы — это всего лишь препроцессор, поэтому они проще шаблонов, как ни крути.

S>Ну и отдельный вопрос: а зачем этот макрос вообще потребовался, ведь на Си так легко и просто понятный код писать, а тут на одном for-е почему-то экономят.

Для итерации в ядре макросов много, включая обычные list, rcu, rb_tree и прочие частные for_each_process() и for_each_device(). Вообще итерация по спискам в ядре довольно специфичная через получение адреса структуры по ее полю list_head, но достаточно один раз разобраться с list, и дальше просто пользоваться остальными макросами. В любом случае если нужно разобраться в участке кода, то у макросов названия достаточно понятные, и они не затрудняют эту задачу.
Контейнеров в ядре в такой форме как в С++ нет, как и классов, — это наверное плохо, должен согласиться. Классический С++ был бы удобнее, но можно писать понятный код и с макросами. Я же не говорю, что С лучше С++98. Хотя для С легче понять где какой метод вызывается без виртуальных функций(аргумент Линуса). Также в С полегче предсказать какой бинарный код получится и разбираться в ассемблерных дампах, что в ядре является плюсом.

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, lpd, Вы писали:

S>что будет, если мне потребуется вместо skb_rbtree_walk_from(skb) написать skb_rbtree_walk_from(skb+1)?

Ты наверное понимаешь, что skb — указатель, и (skb+1) в данном случае смысла не имеет.
Будет просто:

skb=skb_rb_next(skb);
skb_rbtree_walk_from(skb){
}

Так что непонятно в чем твоя претензия в данном случае.

S>Полагаю, разбираться в чужих макросах сильно проще, чем в чужих шаблонах.

Макросы — это всего лишь препроцессор, поэтому они проще шаблонов, как ни крути.

S>Ну и отдельный вопрос: а зачем этот макрос вообще потребовался, ведь на Си так легко и просто понятный код писать, а тут на одном for-е почему-то экономят.

Для итерации в ядре макросов много, включая обычные list, rcu, rb_tree и прочие частные for_each_process() и for_each_device(). Вообще итерация по спискам в ядре довольно специфичная через получение адреса структуры по ее полю list_head, но достаточно один раз разобраться с list, и дальше просто пользоваться остальными макросами. В любом случае если нужно разобраться в участке кода, то у макросов названия достаточно понятные, и они не затрудняют эту задачу.
Контейнеров в ядре в такой форме как в С++ нет, как и классов, — это наверное плохо, должен согласиться. Классический С++ был бы удобнее, но можно писать понятный код и с макросами. Я же не говорю, что С лучше С++98. Хотя для С легче понять где какой метод вызывается без виртуальных функций(аргумент Линуса). Также в С полегче предсказать какой бинарный код получится и разбираться в ассемблерных дампах, что в ядре является плюсом.