Linuxデバイスモデルの詳細説明(4)_sysfs

1 はじめに

sysfs は、Kobject と組み合わせて使用​​される RAM ベースのファイル システムで、カーネル データ構造と属性をユーザー空間にエクスポートし、ファイル ディレクトリ構造の形式でこれらのデータ構造へのアクセス サポートを提供します。

sysfs はファイル システムのすべての属性を備えていますが、この記事では Linux デバイス モデルにおけるその特性に焦点を当てます。したがって、ファイル システム実装の詳細についてはあまり説明せず、デバイス モデルにおける sysfs の役割と使用法のみを紹介します。具体的には:

• sysfs と Kobject
の関係
• 属性の概念
• sysfs
のファイルシステム操作インターフェース

2. sysfs と Kobject の関係

記事「Linux Device Model_Kobject」では、各 Kobject が sysfs 内のディレクトリに対応すると述べられています。したがって、Kobject をカーネルに追加すると、create_dir インターフェイスは sysfs ファイル システムのディレクトリ作成インターフェイスを呼び出して、Kobject に対応するディレクトリを作成します。関連するコードは次のとおりです。 リーリー

3.属性

3.1 属性の機能概要

sysfs にはなぜ属性という概念があるのですか?実際、これは kobject に対応しており、kobject の「属性」を指します。私たちは知っています、

sysfs のディレクトリは kobject を記述しており、kobject は特定のデータ型変数 (struct device など) を具体化したものです。したがって、kobject の属性はこれらの変数の属性になります。名前、内部変数、文字列など、何でも構いません。属性は、sysfs ファイル システム内のファイルの形式で提供されます。つまり、kobject のすべての属性は、対応する sysfs ディレクトリ内のファイルの形式で提供されます。これらのファイルは通常、読み取りおよび書き込み可能であり、これらの属性を定義するカーネル内のモジュールは、ユーザー空間での読み取りおよび書き込み操作に基づいてこれらの属性の値を記録して返します。

要約すると、いわゆる属性は、カーネル空間とユーザー空間の間で情報をやりとりするための方法です。たとえば、ドライバーが変数を定義し、ユーザー空間プログラムがその変数を変更してドライバーの実行動作を制御できることを望む場合、変数を sysfs 属性として開くことができます。

Linux カーネルでは、属性は次のように通常の属性とバイナリ属性に分類されます。 リーリー

struct 属性は通常の属性であり、この属性を使用して生成された sysfs ファイルは文字列形式でのみ読み書きできます (理由は後ほど説明します)。 struct bin_attribute は、struct 属性に基づいて読み取り、書き込み、その他の機能を追加するため、生成される sysfs ファイルは任意の方法で読み書きできます。

基本概念について話した後、2 つの質問をする必要があります:

カーネルはどのようにして属性を sysfs 内のファイルに変換しますか?

ユーザー空間の sysfs ファイルの読み取りおよび書き込み操作をカーネルに渡すにはどうすればよいですか?

プロセスを見てみましょう。

3.2 属性ファイルの作成

Linux カーネルでは、属性ファイルの作成は、fs/sysfs/file.c の sysfs_create_file インターフェイスによって完了します。このインターフェイスの実装には特別なことは何もありません。ほとんどはファイル システム関連の操作であり、デバイス モデルとは関係がないため、ここでは多くの関係を省略します。

3.3 属性ファイルの読み取りと書き込み

3.1 章の struct 属性のプロトタイプを見ると、「この構造は非常に単純だ。name はファイル名を表し、mode はファイル モードを表し、その他のフィールドはカーネル ロックをデバッグするためにカーネルによって使用されます。」とつぶやくかもしれません。次に、ファイルを操作するためのインターフェイスはどこにありますか?

心配しないで、fs/sysfs ディレクトリに移動して、sysfs 関連のコード ロジックを見てみましょう。

すべてのファイル システムは、このファイル システムの操作インターフェイスを記述するために struct file_operations 変数を定義します。sysfs も例外ではありません。

リーリー

属性ファイルの読み取り操作は、VFS から sysfs_file_operations の読み取り (つまり、sysfs_read_file) インターフェイスに転送されます。このインターフェイスの処理ロジックを大まかに見てみましょう。

 1: /* fs/sysfs/file.c, line 127 */
 2: static ssize_t
 3: sysfs_read_file(struct file *file, char __user *buf, size_t count, loff_t *ppos)
 4: {
 5:     struct sysfs_buffer * buffer = file->private_data;
 6:     ssize_t retval = 0;
 7:  
 8:     mutex_lock(&buffer->mutex);
 9:     if (buffer->needs_read_fill || *ppos == 0) {
 10:        retval = fill_read_buffer(file->f_path.dentry,buffer);
 11:        if (retval)
 12:            goto out;
 13:    }
 14: ...
 15: }
 16: /* fs/sysfs/file.c, line 67 */
 17: static int fill_read_buffer(struct dentry * dentry, struct sysfs_buffer * buffer)
 18: {           
 19:    struct sysfs_dirent *attr_sd = dentry->d_fsdata;
 20:    struct kobject *kobj = attr_sd->s_parent->s_dir.kobj;
 21:    const struct sysfs_ops * ops = buffer->ops;
 22:    ...        
 23:    count = ops->show(kobj, attr_sd->s_attr.attr, buffer->page);
 24:    ...
 25: }

“

read处理看着很简单，sysfs_read_file从file指针中取一个私有指针（注：大家可以稍微留一下心，私有数据的概念，在VFS中使用是非常普遍的），转换为一个struct sysfs_buffer类型的指针，以此为参数（buffer），转身就调用fill_read_buffer接口。

而fill_read_buffer接口，直接从buffer指针中取出一个struct sysfs_ops指针，调用该指针的show函数，即完成了文件的read操作。

那么后续呢？当然是由ops->show接口接着处理咯。而具体怎么处理，就是其它模块（例如某个driver）的事了，sysfs不再关心（其实，Linux大多的核心代码，都是只提供架构和机制，具体的实现，也就是苦力，留给那些码农吧！这就是设计的魅力）。

不过还没完，这个struct sysfs_ops指针哪来的？好吧，我们再看看open(sysfs_open_file)接口吧。

”

 1: /* fs/sysfs/file.c, line 326 */
 2: static int sysfs_open_file(struct inode *inode, struct file *file)
 3: {
 4:     struct sysfs_dirent *attr_sd = file->f_path.dentry->d_fsdata;
 5:     struct kobject *kobj = attr_sd->s_parent->s_dir.kobj;
 6:     struct sysfs_buffer *buffer;
 7:     const struct sysfs_ops *ops;
 8:     int error = -EACCES;
 9:  
 10:    /* need attr_sd for attr and ops, its parent for kobj */
 11:    if (!sysfs_get_active(attr_sd))
 12:    return -ENODEV;
 13:  
 14:    /* every kobject with an attribute needs a ktype assigned */
 15:    if (kobj->ktype && kobj->ktype->sysfs_ops)
 16:        ops = kobj->ktype->sysfs_ops;
 17:    else {
 18:        WARN(1, KERN_ERR "missing sysfs attribute operations for "
 19:            "kobject: %s\n", kobject_name(kobj));
 20:        goto err_out;
 21:    }
 22:  
 23:    ...
 24:  
 25:    buffer = kzalloc(sizeof(struct sysfs_buffer), GFP_KERNEL);
 26:    if (!buffer)
 27:        goto err_out;
 28:  
 29:    mutex_init(&buffer->mutex);
 30:    buffer->needs_read_fill = 1;
 31:    buffer->ops = ops;
 32:    file->private_data = buffer;
 33:    ...
 34: }

“

哦，原来和ktype有关系。这个指针是从该attribute所从属的kobject中拿的。再去看一下”Linux设备模型_Kobject”中ktype的定义，还真有一个struct sysfs_ops的指针。

我们注意一下14行的注释以及其后代码逻辑，如果从属的kobject（就是attribute文件所在的目录）没有ktype，或者没有ktype->sysfs_ops指针，是不允许它注册任何attribute的！

经过确认后，sysfs_open_file从ktype中取出struct sysfs_ops指针，并在随后的代码逻辑中，分配一个struct sysfs_buffer类型的指针（buffer），并把struct sysfs_ops指针保存在其中，随后（注意哦），把buffer指针交给file的private_data，随后read/write等接口便可以取出使用。嗯！惯用伎俩！

”

顺便看一下struct sysfs_ops吧，我想你已经能够猜到了。

 1: /* include/linux/sysfs.h, line 124 */
 2: struct sysfs_ops {
 3:     ssize_t (*show)(struct kobject *, struct attribute *,char *);
 4:     ssize_t (*store)(struct kobject *,struct attribute *,const char *, size_t);
 5:     const void *(*namespace)(struct kobject *, const struct attribute *);
 6: };

attribute文件的write过程和read类似，这里就不再多说。另外，上面只分析了普通attribute的逻辑，而二进制类型的呢？也类似，去看看fs/sysfs/bin.c吧，这里也不说了。

讲到这里，应该已经结束了，事实却不是如此。上面read/write的数据流，只到kobject（也就是目录）级别哦，而真正需要操作的是attribute（文件）啊！这中间一定还有一层转换！确实，不过又交给其它模块了。 下面我们通过一个例子，来说明如何转换的。

4. sysfs在设备模型中的应用总结

让我们通过设备模型class.c中有关sysfs的实现，来总结一下sysfs的应用方式。

首先，在class.c中，定义了Class所需的ktype以及sysfs_ops类型的变量，如下：

 1: /* drivers/base/class.c, line 86 */
 2: static const struct sysfs_ops class_sysfs_ops = {
 3:     .show      = class_attr_show,
 4:     .store     = class_attr_store,
 5:     .namespace = class_attr_namespace,
 6: };  
 7: 
 8: static struct kobj_type class_ktype = {
 9:     .sysfs_ops  = &class_sysfs_ops,
 10:    .release    = class_release,
 11:    .child_ns_type  = class_child_ns_type,
 12: };

由前面章节的描述可知，所有class_type的Kobject下面的attribute文件的读写操作，都会交给class_attr_show和class_attr_store两个接口处理。以class_attr_show为例：

 1: /* drivers/base/class.c, line 24 */
 2: #define to_class_attr(_attr) container_of(_attr, struct class_attribute, attr)
 3:  
 4: static ssize_t class_attr_show(struct kobject *kobj, struct attribute *attr,
 5: char *buf)
 6: {   
 7:     struct class_attribute *class_attr = to_class_attr(attr);
 8:     struct subsys_private *cp = to_subsys_private(kobj);
 9:     ssize_t ret = -EIO;
 10:  
 11:    if (class_attr->show)
 12:    ret = class_attr->show(cp->class, class_attr, buf);
 13:    return ret;
 14: }

该接口使用container_of从struct attribute类型的指针中取得一个class模块的自定义指针：struct class_attribute，该指针中包含了class模块自身的show和store接口。下面是struct class_attribute的声明：

 1: /* include/linux/device.h, line 399 */
 2: struct class_attribute {
 3:     struct attribute attr;
 4:     ssize_t (*show)(struct class *class, struct class_attribute *attr,
 5:                     char *buf);
 6:     ssize_t (*store)(struct class *class, struct class_attribute *attr,
 7:                     const char *buf, size_t count);
 8:     const void *(*namespace)(struct class *class,
 9:                                 const struct class_attribute *attr); 
 10: };

因此，所有需要使用attribute的模块，都不会直接定义struct attribute变量，而是通过一个自定义的数据结构，该数据结构的一个成员是struct attribute类型的变量，并提供show和store回调函数。然后在该模块ktype所对应的struct sysfs_ops变量中，实现该本模块整体的show和store函数，并在被调用时，转接到自定义数据结构（struct class_attribute）

以上がLinuxデバイスモデルの詳細説明(4)_sysfsの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。