私の立ち位置では、DeviceTreeの存在意義が全く分からない。
DeviceTreeとは、ハードウェア設定をスクリプト形式で記述し、Kernelへ橋渡しすることで、ハードウェアの差異をスムーズに吸収することを狙ったものである。Intel PCには無く、ある時期以降のPowerPCとARMで利用されている仕組みである。組込Linuxでは、U-BootとKernelの間に位置する。
ディベロッパーサイドで言わせてもらうと、これは、混沌しか生み出していない。そもそも、U-BootとKernelの間だけであっても、ペリフェラル設定をどちらが実施するかで悩むことがある。Ethernet関連やPCI関連のデバイス設定は、U-BootとKernelで重複設定しているケースや、邪魔しているケースもある。そこへ、DeviceTreeが割って入って来たので、混沌しか生まれない。Kernelがデバイス設定パラメータを受け取るルートが増えただけである。
例えば・・・、LANのPHYチップにRGMII/SGMII等の高速インタフェースがあるケースでは、たいてい、デバイス設定でスキュー調整を行うが、この設定ルートになりうる下記の①〜④が、カード種別／PHYチップ／Kernelバージョンでばらばらである。しかも、重複設定もある。
① U-Boot → Kernel
② Kernel内単独でパラメータ設定
③ DeviceTree → U-Boot → Kernel
④ DeviceTree → Kernel
昔は①か②であったが、②だけでは、U-BootでLANが使えず、開発ではNG。U-Boot側での設定は必要。その意味では、④もNG（または重複設定）。
更に、構成管理物が１個増え、それがH/WとS/Wの中間にあるものだから、ハード屋／ソフト屋どっちで開発・管理等めんどうを見ていくかでもめることになる。
Linuxの第一理念である汎用性を狙ったものなのだろうが、DeviceTreeによって何か恩恵を受けた人は、はたしているのだろうか？。
https://www.devicetree.org/specifications/
もしDeviceTreeが無かったら・・・
https://youtu.be/UURuqxzuEls?t=1013
どうやら、Kernelツリーにおけるソースコードの膨張を吸収する役割を果たしているようです。例えば、ボードに特化したパラメータの入ったパッチはKernelのソースツリー本体にはコミットされず、そうしたボード固有情報はDeviceTreeに外出しさせることで、ソースツリー本体のバリエーション拡大や#define列挙でのコード増大を防いだのでしょう。別の立ち位置から見ればDeviceTreeの存在意義はあるわけであり、T様の怒りを沈めるべく尽力された方々に深く御礼申し上げます。
