目次
序文：
古典的なリンク:私は常に、質問を考えて練習することで、理解と学習が容易になると信じてきました。
(1) 駆動設計の核となる考え方
- オブジェクト指向
- 層状の
- 別
(2) 駆動フレームワークは何ですか?
- 伝統的な枠組み
- バスデバイスドライバーフレームワーク
- デバイスツリー
書くのは簡単ではありません。もし役に立ったら、サポートしてください。一緒に進歩しましょう! 先人の考え方は本当に巧妙ですね！！！
参考研究:
1. ウェイ先生のコース
2. Linux ノート https://xuesong.blog.csdn.net/article/details/109522945?spm=1001.2014.3001.5502
1. ドライブの設計
9. design_object-志向_layered_separation_哔哩哔哩_bilibiliを推進するアイデア
現在、ドライバー開発作業のほとんどは、以前の作業に基づいて修正および改善されているため、私たちは彼が使用するドライバー設計のアイデアを学び、理解する必要があります。そうすれば、対応する改善と完成度をどこで完了するかを知ることができます。
ドライバーの学習はドライバーの役割を認識することです Linux システム上のドライバーとベアメタル マイクロコントローラー上のドライバーの違いは何ですか? なぜドライバー フレームワークのようなものが必要なのでしょうか? 次のブログ投稿を参照してください。
https://blog.csdn.net/weixin_42373086/article/details/129764065?spm=1001.2014.3001.5501
以前のアプリケーション開発を学習すると、Linux システムは多くのデバイスを処理する必要があるため、データをどのように管理、制御、処理するかが比較的大きな問題であることがよくわかります。特に今後の開発プロセスにおいては、機器の変更やプログラムのバージョン変更にいかに迅速に対応して開発を進めるかが大きな課題となります。
それぞれのデバイスは関連する特性や属性を持ち、それがオブジェクトであり、その後、オブジェクトが階層化（アナログ、皮膚筋）され、最後にさらに深いレベル（同一クラスの共通性や特性）で分解・分離されます。
設計を推進するという考え方は、上で述べたように、オブジェクト指向であり、階層化され、分離されています。
(1) オブジェクト指向:
キャラクターデバイスドライバーでは、file_operations 構造体が抽象化され、オブジェクトを表すために特定の実装関数 (open/read/write) が提供されます。（適切な構造をいかに抽象化するか、これは内面の強さが試されます、笑）
(2) レイヤリング:
複数のボードを扱う場合、同じドライバーを呼び出す必要があります。ドライバーが複数のボードをサポートするようにするにはどうすればよいですか? レイヤ化の考え方は、ここではたとえばキャラクターデバイスドライバーに適用されます。
- 上位層は、キャラクターデバイスドライバーの登録など、ハードウェアに依存しない操作を実装します。
- 下位層はハードウェア関連の操作を実装します。
(3) 分離：
LED ドライバーを例として、LED を制御するピンを変更する場合を考えます。これにはピンの初期化と設定が含まれます。特定のチップのすべての GPIO 動作は似ています。ここでは、より一般的なハードウェア オペレーション コード (chipY_gpio.c) を記述できます。
上図をまとめると、board_A.cとboard_B.cでリソースを定義し、chipY_gpio.cで分離を実現するためのハードウェアの共通コードとして、左右の分離が可能です。
ここでは、特定のリソースを表すために構造体 led_resource が抽象化されています。
2. ドライバーフレームワーク
10. ドライバー進化への道_バスデバイスドライバーモデル_哔哩哔哩_bilibili
(1) 従来の枠組み
ここでどのピンを使用し、そのピンをどのように操作するかはコードに書かれています。
このフレームワークはスケーラビリティを考慮しておらず、すぐに機能を実装できますが、ピンの変更に関しては再コンパイルが必要です。
(2) バスデバイスドライバーフレームワーク:
デバイス(led)があると管理するための構造体(led_resource)を作成するのが非常に面倒
分離の考え方を応用し、さらに拡張してplatform_device/platform_driverを導入し、リソース(デザイン)を「ドライバー」(ドライバー)から分離します。
上記の分離後も、次のような複数のデバイス タイプの定義が表示されることがわかりますが、これらは統一的に管理できますか? ここでは、分離のアイデアをよりよく実現するためにバスの概念が導入されています。
上記のモデルを単純化すると、次の図が表示されます: https://live.csdn.net/v/269203?spm=1001.2014.3001.5501
Linux のデバイス ドライバー管理では、オブジェクトの概念を使用して、さまざまなデバイス、バス、ドライバーを管理します。
バス (bus): 対応するバスをマウントするデバイスとドライバーの管理を担当します。
デバイス: バス上にマウントされた物理デバイス。
ドライバー: デバイスを初期化し、デバイスを操作する何らかの手段を提供する、特定のデバイスに関連付けられたソフトウェア。
クラス（class）：同じ機能を持つ機器を1つのカテゴリにまとめて分類管理します。
バスはデバイスとドライバーをどのように管理しますか?
subsys_private、バスのドライバー コアのプライベート データです。subsys_private データ構造の下に 2 つのリンク リストがあり、1 つはデバイスのマウント用、もう 1 つはドライバーのマウント用で、デバイスとドライバーの管理を実現していることがわかります。
(3) デバイスツリー
実際の開発ではボードごとに.cリソースファイルが存在するため、それらをすべてLinuxカーネルに入れるとカーネルが肥大化してしまいます。
ここでは dts 設定ファイルを導入して管理します。dts ファイルは dtb ファイルをコンパイルし、カーネルに渡します。カーネルは dtb を解析し、一連の platform_device/platform_driver ファイルを生成します。
ここでは、dtb ファイルと dts ファイルの両方がカーネルの外部にあることがわかります。これにより、カーネルが合理化され、エレガントになります。