結論として、af_packet.c が bitmap_free を直接インクルードしていないにもかかわらず同関数を利用できる理由は、bitmap_free がヘッダによるインライン定義ではなく、カーネル全体に公開された「外部シンボル」としてエクスポートされているためです。
すなわち、関数宣言を含むヘッダを直接インクルードしていなくても、コンパイル時とリンク時のルールにより、呼び出し自体は成立します。
状況を整理します。
bitmap_free は lib/bitmap.c で定義され、EXPORT_SYMBOL(bitmap_free) によってカーネルの他コンポーネントから参照可能な外部シンボルとなっています。
このため、ビルド後の vmLinux やモジュールリンク時に、bitmap_free という名前で公開されている関数にリンクされます。
問題は、型宣言がどこで提供されているかです。
関数を呼び出すためには、通常はそのプロトタイプ宣言が必要です。
しかし、C 言語では、プロトタイプが無い関数を呼び出すと暗黙の宣言が行われるという仕様がかつて存在していました。
Linux カーネルは古くからの C89 の流儀を一部引きずっており、特に 4.14 の時代には、プロトタイプが無い関数を呼び出した場合でもコンパイルが通るケースが残っています。
bitmap_free(const unsigned long *bitmap) の戻り値は void であり、引数型も単純なポインタです。
このような関数は暗黙宣言による不整合が起きにくいため、宣言なしで呼んでもコンパイラが致命的エラーにしません。
実際、af_packet.c 側は bitmap_free のプロトタイプを知らないまま呼び出していますが、戻り値型が void のため暗黙宣言でも問題が表面化しません。
一方で、関数参照が成立するのは、リンク時に外部シンボルとして bitmap_free が解決できるためです。
EXPORT_SYMBOL により、lib/bitmap.o 内のラベル bitmap_free がカーネル全体に公開され、af_packet.o からの未解決シンボルがリンクステージで解決されます。
整理すると、次の二点が理由となります。
bitmap_free が EXPORT_SYMBOL によって公開されたリンク可能な外部シンボルであること。
af_packet.c が関数宣言をインクルードしていないが、カーネルビルドの設定や戻り値が void であることにより、コンパイル時に暗黙宣言エラーとはならず、リンク時に解決されること。
補足すると、現在の Linux カーネルではこのような暗黙宣言は警告やエラーの対象であり、bitmap_free を使うソースでは本来 \u0026lt;Linux/bitmap.h\u0026gt; をインクルードするべきです。
4.14 の頃は暗黙宣言がまだ混在していましたが、新しいカーネルでは strict-prototypes が必須となり、このようなコードは許されなくなっています。
