任意にsk_を拡張する方法buffカーネルを再コンパイルしない
Linuxネットワークを游ぶ同好はきっと任意にネットワーク処理ロジックの行为を定义することができることを望んで、プロトコル処理のハイエンドのカスタマイズと言えて、最も明らかな方法は构造体の中で1つのフィールドをプラスして、事実上Linuxの1つの入口のフローコントロールのパッチIMQはこのようにして、それは简単にLinuxカーネルのsk_を修正しましたbuff構造体の定義、フィールドの追加、IMQで使用されるフィールドの追加、カーネルの再コンパイル... カーネルを再コンパイルすることで、いつもニーズを満たすことができますが、悪夢自体はカーネルを再コンパイルすることです!私は特にカーネルを再コンパイルするのが嫌いです.貴重で限られた時間を浪費しているからです.また、このようなやり方はあまりにも挿入されず、場面が大きすぎます.Linuxカーネルコードはいつオブジェクト向け言語のように任意に拡張できますか?はい、LKMは可能ですが、ネットワークプロトコルスタックはコア機能としてLKMによって実現されるわけではありませんので、再コンパイルするか再コンパイルするかを除きます. 最近1冊の《JAVAプログラミング思想》を買って、ずっとこの本がいったいどんな思想を体現しているのかに悩んで、たくさん読んで、少し考えがあって、対象、対象の思想はこの本の核心で、注意して、多態ではありませんて、対象自身です.オブジェクトの利点は、拡張性、完全な拡張性にあります.だからこの考えに従って、私は一労永逸の仕事をして、sk_buffは拡張可能です. Linuxカーネルは構造体の拡張を常に考慮しているため、多くの構造体にはprivate_というものが含まれています.dataのフィールドは、privateやprivなどとも呼ばれます.実際、ほとんどのC言語で書かれたフレームワークは、file構造体のような類似の思想を採用しています.
私が誰に与えた値を見てみましょうか.fに与えられた値です.fはタイプではなく、オブジェクトです.この意味では、タイプは何ですか.struct fileです.file構造体の拡張が必要です.OOの考えによれば、私はそうすべきです.
考えを理解してから、私たちはコードの修正に着手することができて、とても簡単で、もっと通用するために、私たちはただ1つのポインタを拡張することを望んで、ポインタは本当にC言語の1つの芸術で、それは1次元のメモリを多次元に拡張することができて、それはいかなるものを指すことができます.しかし、skbを割り当てるとき、そのポインタがどこを指しているのか、具体的なタイプも分からないので、メモリを予め割り当てるだけでいいので、メモリが価値がない今日、複数のバイトがいい(多くの弊害は資源が乏しい段階から受け継がれている.例えば、倹約など).
PREROUTINGで呼び出す:
Linuxプロトコルスタック伝達skbの不合理性
Linuxは完全に合理的ではなく、OOの思想でプロトコルスタックを再構築して実現したい場合は、既存のフレームワークが適切ではありません.
1.skbは割当て後に再定義できない
skbは、パケットがプロトコルスタックに入った後に一度だけ割り当てられ、その後プロトコルスタックから離れるまで、そのデータポインタを移動するだけで今どのレイヤに着いたかを示し、どのレイヤの処理関数でもskbの構造体自体は変更できない.この考え方は実際には最初に効率のために導入されたもので、『TCP/IP詳細解(第2巻実現)』を見たことがあると、以前のUNIX mbufはまったく使われていなかったことがわかります.実際には、mbufメカニズムは各層で再定義されており、効率は低いように見えますが、今日は本物に戻ると、OOの考えを体現しています.
Linuxのskbが一度だけ割り当てられることは、skbデータの指示に基づいてskbをルーティングするか、skb内部のフィールドの値を変更するしかないことを意味しますが、skb自体を変更することはできません.つまり、現在のskbを解放してから、新しいskbを割り当てて代わりにするか、古いskbの内容を新しいskbにコピーして、新しいskbに新しいものを追加することはできません.
2.LinuxのNetfilterフレームワークはLinuxプロトコルスタックの処理方式を完全に継承している
NF_HOOK戻り値はプロトコルスタックの戻り値、すなわちint型の値であり、成功または失敗を表す.でもどうして?
struct file {
....
/* needed for tty driver, and maybe others */
void *private_data;
....
};struct file *f = ....;
f->private_data = ...;私が誰に与えた値を見てみましょうか.fに与えられた値です.fはタイプではなく、オブジェクトです.この意味では、タイプは何ですか.struct fileです.file構造体の拡張が必要です.OOの考えによれば、私はそうすべきです.
struct txtfile_extends_file {
struct file f;
void *private;
};f1->private = a;
...
f1->private = b;struct txtfile1_extends_file {
struct file f;
void *private1;
};struct txtfile2_extends_file {
struct file f;
void *private2;
};考えを理解してから、私たちはコードの修正に着手することができて、とても簡単で、もっと通用するために、私たちはただ1つのポインタを拡張することを望んで、ポインタは本当にC言語の1つの芸術で、それは1次元のメモリを多次元に拡張することができて、それはいかなるものを指すことができます.しかし、skbを割り当てるとき、そのポインタがどこを指しているのか、具体的なタイプも分からないので、メモリを予め割り当てるだけでいいので、メモリが価値がない今日、複数のバイトがいい(多くの弊害は資源が乏しい段階から受け継がれている.例えば、倹約など).
void __init skb_init(void)
{
skbuff_head_cache = kmem_cache_create("skbuff_head_cache",
sizeof(struct sk_buff) + sizeof(char *),
0,
SLAB_HWCACHE_ALIGN|SLAB_PANIC,
NULL);
skbuff_fclone_cache = kmem_cache_create("skbuff_fclone_cache",
(2*(sizeof(struct sk_buff) + sizeof(char *))) +
sizeof(atomic_t),
0,
SLAB_HWCACHE_ALIGN|SLAB_PANIC,
NULL);
}struct data_extends_skb {
struct sk_buff skb;
char *info;
};PREROUTINGで呼び出す:
struct data_extends_skb *des = (struct data_extends_skb *)skb;
strcpy(des->info, "abcdefg", 6);memcpy(skb + 1, 0, sizeof(char *));Linuxプロトコルスタック伝達skbの不合理性
Linuxは完全に合理的ではなく、OOの思想でプロトコルスタックを再構築して実現したい場合は、既存のフレームワークが適切ではありません.
1.skbは割当て後に再定義できない
skbは、パケットがプロトコルスタックに入った後に一度だけ割り当てられ、その後プロトコルスタックから離れるまで、そのデータポインタを移動するだけで今どのレイヤに着いたかを示し、どのレイヤの処理関数でもskbの構造体自体は変更できない.この考え方は実際には最初に効率のために導入されたもので、『TCP/IP詳細解(第2巻実現)』を見たことがあると、以前のUNIX mbufはまったく使われていなかったことがわかります.実際には、mbufメカニズムは各層で再定義されており、効率は低いように見えますが、今日は本物に戻ると、OOの考えを体現しています.
Linuxのskbが一度だけ割り当てられることは、skbデータの指示に基づいてskbをルーティングするか、skb内部のフィールドの値を変更するしかないことを意味しますが、skb自体を変更することはできません.つまり、現在のskbを解放してから、新しいskbを割り当てて代わりにするか、古いskbの内容を新しいskbにコピーして、新しいskbに新しいものを追加することはできません.
2.LinuxのNetfilterフレームワークはLinuxプロトコルスタックの処理方式を完全に継承している
NF_HOOK戻り値はプロトコルスタックの戻り値、すなわちint型の値であり、成功または失敗を表す.でもどうして?
#define NF_HOOK_THRESH(pf, hook, skb, indev, outdev, okfn, thresh) \
({int __ret; \
if ((__ret=nf_hook_thresh(pf, hook, (skb), indev, outdev, okfn, thresh, 1)) == 1)\
__ret = (okfn)(skb); \
__ret;})
#define NF_HOOK_THRESH(pf, hook, skb, indev, outdev, okfn, thresh) \
({struct sk_buff *__skb2, __ret; \
if ((__skb2=nf_hook_thresh(pf, hook, (skb), indev, outdev, okfn, thresh, 1)) != NULL)\
__ret = (okfn)(__skb2); \
__ret;})
....// nf_hook_thresh struct sub_extends_skb {
struct sb_buff skb;
type1 v1;
type2 v2;
type3 v3;
...
};
struct sub_extends_skb *sub_construct (struct sb_buff *skb)
{
struct sub_extends_skb = _k_malloc_and_skb_copy(sizeof(sub_extends_skb), skb);
ses->v1 = ...;
...
return ses;
}
struct sub_extends_skb *ss;
if (...) {
ss = construct(skb);
} else {
ss = skb;
}
... // process
return ss;
char *p = (char *)0;
*p = 'a';
...