Non Lasting Storage File System、procfs、sysfs

catalog

0. 引言
1. proc文件系统
2. 简单的文件系统
3. sysfs

0. 引言

传统上，文件系统用于在块设备上持久存储数据，但也可以使用文件系统来组织、提供、交换并不存储在块设备上的信息，这些信息可以由内核动态生成，VFS的虚拟抽象层从架构上提供了这种功能，我们接下来着重讨论几种无持久存储的文件系统

1. proc文件系统(proc filesystem)
它使得内核可以生成与系统的状态和配置有关的信息，该信息可以由用户和系统程序从普通文件读取，而无需专门的工具与内核通信(通过简单的文件操作即可)，在某些情况下，一个简单的cat命令即可完成。数据不仅可以从内核读取，还可以通过向proc文件系统的文件写入字符串，来向内核发送数据，例如echo >> xx
该方法利用了一个虚拟文件系统"即时"产生文件信息，即只有在向proc文件系统发出读操作请求时，才会动态生成信息，对于此类文件系统，不需要专门的硬盘分区或其他块存储设备

2. Sysfs
它与procfs目的类似，默认装载在/sys目录，但并不是强制规定，它设计为从内核向用户层导出非常结构化的信息，与procfs相比，它并不提供用户直接使用，因此信息是层次化、深度嵌套的。此外，文件包含的信息并不总是ASCII文本形式，也有可能使用不可读的二进制串，Sysfs对于想要收集系统中的硬件和设备间拓朴关联方面详细信息的工具而言，是非常有用的
还可以对使用kobject的内核对象创建sysfs项，这使得用户层很容易访问内核中重要的核心数据结构

3. 用于专门目的的小文件系统
可以由内核提供的标准函数构建，在内核内部，libfs库提供了所需功能。此外，内核提供了易于实现顺序文件的方法，在调试文件系统debugfs中同时使用了这两种技术，该文件系统使得内核开发者能够快速地向用户空间导出值、或从用户空间导入值，而无需创建定制的接口或专门的文件系统

Relevant Link:

1. proc文件系统

我们知道，proc文件系统是一种虚拟文件系统，其信息不能从块设备读取，只有在发起文件读取请求时，才由内核动态生成相应的信息。使用proc文件系统，可以实现以下优点

1. 可以获得有关内核各子系统的信息，例如
    1) 内存利用率
    2) 附接的外设等)
2. 不重新编译内核源代码的情况下修改内核的行为，或重启系统

与该文件密切相关的是系统控制机制(system control mechanism sysctl)，proc文件系统提供了一种接口，可用于该机制导出的所有选项，使得可以很容易的修改参数，无需开发专门的通信程序，只需要一个标准的shell和标准的cat、echo程序
通常，进程数据文件系统(process data filesystem procfs)装载在/proc，需要明白的是，该文件系统可以装载到目录树的任何位置，就像是其他任何文件系统一样

0x1: /proc的内容

尽管proc文件系统的容量依系统而不同(根据硬件配置导出不同的数据，不同的体系结构也会影响内容)，其中仍然包含了普遍存在的许多深层嵌套的目录、文件、链接，大致可以分为以下几大类

1. 内存管理
2. 系统进程的特征数据
3. 文件系统
4. 设备驱动程序
5. 系统总线
6. 电源管理
7. 终端
8. 系统控制参数

从内核开发的趋势来看，正在远离使用proc文件系统提供信息的方法，而倾向于采用特定于问题的虚拟文件系统来导出数据，例如USB文件系统，将与USB子系统有关的许多状态信息导出到用户空间，而没有给/proc增加新的负担。此外，Sysfs文件系统提供了一种层次化的视图，不仅包括设备树(包括系统总线、PCI设备、CPU等)，还有重要的内核对象
我们接下来逐个讨论/proc中各个文件及其内容的相关知识

1. 特定于进程的数据

每个系统进程，无论当前状态如何，都有一个对应的子目录(与PID同名)，包含了该进程的有关信息

1. cmdline: 进程的命令行，一个用"\0"分隔的字符串，包含了程序名和所有参数
2. environ: 表示为该进程设置的所有环境变量，使用了"\0"作为分隔符
3. maps: 列出了进程使用的所有库(和进程本身的二进制文件)的内存映射
4. status: 包含了有关进程状态的一般信息
    1) UID/GID
    2) 内存分配
    3) 进程能力
    4) 各个信号掩码的状态(待决、阻塞等)
5. stat、statm: 以一连串数字的形式，提供了进程及其内存消耗的更多状态信息
6. fd子目录: 包含了一些数字名字的文件，这些文加名表示进程的各个文件描述符，这里的每个文件都是一个符号链接，指向文加名对应的文件描述符在文件系统中的位置
7. cwd: 指向进程当前工作目录，如果用户有适当的权限，则可以使用cd cwd切换到该目录，而无需知道cwd具体指向哪个目录
8. exe: 指向包含了应用程序代码的二进制文件
9. root: 指向进程的根目录，但这并一定是全局的根目录(尤其是在chroot模式下)

2. 一般性系统信息

不仅/proc的子目录包含了信息，/proc本身也包含了一些信息，与特定的内核子系统无关的一般信息，一般存放在/proc下的文件中

1. iomem: 提供了用来和设备通信的内核地址
2. ioports: 提供了用来和设备通信的端口信息
3. buddyinfo: 提供了伙伴系统的当前使用情况
4. slabinfo: 提供了slab分配器的当前使用情况
5. meminfo: 给出了一般性的内存使用情况
    1) 高端内存
    2) 低端内存
    3) 空闲内存
    4) 已分配内存
    5) 共享区域
    6) 交换内存
    7) 回写内存
    ..
7. Vmstat: 给出了内存管理的其他特征信息，包括当前在内存管理的各个子系统中内存页的数目
8. kallsyms: 用于支持内核代码调试，是一个符号表，给出了所有全局内核变量和函数在内核内存中的地址
9. kcore: 用于支持内核代码调试，是一个动态的内核文件，"包含"了运行中的内核的所有数据，即主内存的全部内容，与用户应用程序发生致命错误时进行内存转储所产生的普通内核文件；类似，可以将调试器用于该二进制文件，来查看运行中系统的当前状态
10. interrupts: 保存了当前操作期间引发的中断说明，其中国不仅给出了中断的数目，还对每个中断号，都给出相关设备的名称或负责处理中断的驱动程序
11. loadavg: 给出了过去60s、5分钟、15分钟的平均系统负荷(即运行队列的长度)
12. uptime: 给出了系统的运行时间

3. 网络信息

/proc/net子目录提供了内核的各种网络选项的有关数据，其中保存了各种协议和设备数据，包括了以下几个数据项

1. udp、tcp: 提供了IPv4的UDP、TCP套接字的统计数据
2. udp6、tcp6: IPv6的对应数据
3. unix: UNIX套接字的统计信息
4. arp: 用于反向地址解析的ARP表
5. dev: 保存了通过系统的网络接口传输的数据量的统计数据(包括换回接口)，该信息可用于检查网络的传输质量，因为其中也包括了传输不正确的数据包、被丢弃的数据包和冲突相关的数据

4. 系统控制参数

用于动态地检查、修改内核行为的系统控制参数，在proc文件系统的数据项中，属于最多的一部分，但只并不是修改相关数据的唯一方法，还可以使用sysctl系统调用，sysctl实际上是不需要的，因为通过/proc接口对内核数据的操作已经很简单了，sysctl参数由一个独立的子目录/proc/sys管理，它进一步划分为各种子目录，对应于内核的各个子系统

[[email protected] ~]# ll /proc/sys
total 0
dr-xr-xr-x 2 root root 0 Jun 12 11:15 abi
dr-xr-xr-x 2 root root 0 Jun 12 11:15 crypto
dr-xr-xr-x 2 root root 0 Jun 12 11:15 debug
dr-xr-xr-x 7 root root 0 Jun 12 11:15 dev
dr-xr-xr-x 6 root root 0 May 22 16:24 fs
dr-xr-xr-x 5 root root 0 Jun 12 11:15 kernel
dr-xr-xr-x 6 root root 0 Jun 12 11:15 net
dr-xr-xr-x 2 root root 0 Jun 12 11:15 vm
//各个子目录中包含了一系列文件，反映了对应的内核子系统的特征数据，这些文件不仅可以读，还可以通过普通的文件操作，向其中写入新值

0x2: 数据结构

proc大量使用了VFS的数据结构，因为作为一种文件系统，它必须集成到内核的VFS抽象层中，此外还有一些特定于proc的数据结构，用于组织内核提供的数据，还必须提供一个到内核各个子系统的接口，使得内核能从其数据结构中提取信息，然后借助/proc提供给用户空间

1. proc数据项的表示

proc文件系统的每个数据项都由proc_dir_entry的一个实例描述
\linux-2.6.32.63\include\linux\proc_fs.h

struct proc_dir_entry
{
    //inode编号
    unsigned int low_ino;

    //指定了文件名的长度
    unsigned short namelen;
    //指向存储文件名的字符串的指针
    const char *name;

    /*
    mode的语义与普通文件系统相同，因为该成员反映了
    1. 对应数据项的类型
        1) 文件
        2) 目录
        ..
    2. 访问权限的分配
        1) 所有者
        2) 组
        3) 其他
    uid、gid指定了该文件所有和的用户ID、组ID，二者都设置为0，这意味着root用户几乎似乎所有proc文件的所有者
    */
    mode_t mode;

    //proc文件系统中的每个数据项，都对应于一个独立的proc_dir_entry实例，内核借助它来表示文件系统的层次结构

    //nlink指定了目录中子目录和符号链接的数目，
    nlink_t nlink;
    uid_t uid;
    gid_t gid;

    //size成员表示按字节自算的文件长度，由于proc数据项是动态生成的，所以文件的长度通常无法预先知道，在这种情况下，该值为0
    loff_t size;

    //指向inode_operations
    const struct inode_operations *proc_iops;
    /*
     * NULL ->proc_fops means "PDE is going away RSN" or
     * "PDE is just created". In either case, e.g. ->read_proc won‘t be
     * called because it‘s too late or too early, respectively.
     *
     * If you‘re allocating ->proc_fops dynamically, save a pointer
     * somewhere.
     */
    //指向file_operations，这些操作充当了与虚拟文件系统之间的接口
    const struct file_operations *proc_fops;
    struct proc_dir_entry *next, *parent, *subdir;
    void *data;

    /*
    read_proc、write_proc指向的函数分别支持从/向内核读取/写入数据
    */
    read_proc_t *read_proc;
    write_proc_t *write_proc;
    atomic_t count;        /* use count */
    int pde_users;    /* number of callers into module in progress */
    spinlock_t pde_unload_lock; /* proc_fops checks and pde_users bumps */
    struct completion *pde_unload_completion;
    struct list_head pde_openers;    /* who did ->open, but not ->release */
};

2. proc inode

内核提供了一个数据结构，称之为proc_inode，支持以面向inode的方式来查看proc文件系统的数据项，该结构用来将特定于proc的数据与VFS层的inode数据关联起来
\linux-2.6.32.63\include\linux\proc_fs.h

union proc_op
{
    int (*proc_get_link)(struct inode *, struct path *);
    int (*proc_read)(struct task_struct *task, char *page);
    int (*proc_show)(struct seq_file *m,
        struct pid_namespace *ns, struct pid *pid,
        struct task_struct *task);
};

struct proc_inode
{
    struct pid *pid;
    int fd;
    union proc_op op;

    //pde指向关联到proc数据项的proc_dir_entry实例
    struct proc_dir_entry *pde;
    struct ctl_table_header *sysctl;
    struct ctl_table *sysctl_entry;

    //inode实例
    struct inode vfs_inode;
};

可以看到，proc和VFS层用于inode管理的数据组织方式如出一辙，在关联到proc文件系统的每个inode结构实例之前，内存中都有一些额外的数据属于对应的proc_inode实例，根据inode信息，可使用container_of机制获得proc_indoe
0x3: 初始化

在使用proc文件系统之前，必须用mount装载它，而内核必须建立并初始化几个数据结构，以便在内核内存中描述该文件系统的结构，需要注意的，/proc的外观和内容随着平台和体系结构的变化很大，代码中充满了#ifdef预处理器语句，并根据特定情况来选择适当的代码
\linux-2.6.32.63\fs\proc\root.c

void __init proc_root_init(void)
{
    int err;

    //使用proc_init_inodecache为proc_inode对象创建一个slab缓存，这些对象是proc文件系统的支柱，通常需要尽快创建和销毁
    proc_init_inodecache();

    //调用register_filesystem，将该文件系统正式的注册到内核
    err = register_filesystem(&proc_fs_type);
    if (err)
        return;

    //kern_mount_data是do_kern_mount的一个包装器函数，它返回一个指向vfsmount实例的指针，该指针保存在全局变量proc_mnt中，供内核在以后使用
    proc_mnt = kern_mount_data(&proc_fs_type, &init_pid_ns);
    err = PTR_ERR(proc_mnt);
    if (IS_ERR(proc_mnt))
    {
        unregister_filesystem(&proc_fs_type);
        return;
    }

    proc_symlink("mounts", NULL, "self/mounts");

    //内核调用proc_net_init在/proc/net下建立很多与网络相关的文件
    proc_net_init(); 

    /*
    创建子目录，下述列表的每个名字，都会调用create_proc_read_entry，该函数创建一个proc_dir_entry数据结构新实例
    对应的read_proc成员设置为与各个名称相关联的函数
    */
#ifdef CONFIG_SYSVIPC
    proc_mkdir("sysvipc", NULL);
#endif
    proc_mkdir("fs", NULL);
    proc_mkdir("driver", NULL);
    proc_mkdir("fs/nfsd", NULL); /* somewhere for the nfsd filesystem to be mounted */
#if defined(CONFIG_SUN_OPENPROMFS) || defined(CONFIG_SUN_OPENPROMFS_MODULE)
    /* just give it a mountpoint */
    proc_mkdir("openprom", NULL);
#endif
    proc_tty_init();
#ifdef CONFIG_PROC_DEVICETREE
    proc_device_tree_init();
#endif
    proc_mkdir("bus", NULL);
    proc_sys_init();
}

进一步的目录初始化工作，不再由proc层自身负责，而是由提供相关信息的其他内核部分接手，内核负责将这些子目录的proc_dir_entry实例保存到全局变量中的原因也在于此，例如/proc/net中的文件就是由网络层创建的，在网卡驱动或协议初始化时创建，这可以在启动期间完成(对于持久编译到内核中的驱动程序而言)，也可以在系统运行时进行(即加载模块时)，无论如何，都是在proc_root_init初始化proc文件系统仔皇后，如果内核不使用全局变量，就必须提供函数用于注册特定于子系统的数据项，这明显没有使用全局变量优雅
在内核中定义一个新的sysctl时，系统控制机制就会建立对应的文件，并添加到proc_sys_root中
0x4: 装载proc文件系统

在内核内部用于描述proc文件系统结构和内容的数据已经初始化之后，下一步是将该文件系统装载到目录树中
从用户空间系统管理员的角度来看，/proc的装载几乎与非虚拟文件系统是等同的

mount -t proc /proc

以下简要描述VFS内部装载新文件系统的处理流程
\linux-2.6.32.63\fs\proc\root.c

1. 在内核添加新文件系统时，会扫描一个链表，查找与该文件系统相关的file_system_type实例，该实例提供了如何读取对应文件系统超级块的一些信息，对于proc文件系统，该结构初始化如下
/*
static struct file_system_type proc_fs_type =
{
    .name        = "proc",
    .get_sb        = proc_get_sb,
    .kill_sb    = proc_kill_sb,
};
*/

2. 将特定于文件系统的超级块数据填充到一个vfsmount结构的实例中，使得新的文件系统能够集成到VFS树中

可以看到，proc文件系统的超级块由proc_get_sb提供，该函数基于另一个内核辅助例程(get_sb_single)，借助proc_fill_super来填充一个super_block的新实例
\linux-2.6.32.63\fs\proc\inode.c

int proc_fill_super(struct super_block *s)
{
    struct inode * root_inode;

    s->s_flags |= MS_NODIRATIME | MS_NOSUID | MS_NOEXEC;

    //块长度不能设置，总是1024
    s->s_blocksize = 1024;
    //2^10 = 1024
    s->s_blocksize_bits = 10;
    /*
    借助预处理器，用于识别proc文件系统的魔数定义为0x9fa0
    对proc文件系统来说，该数字实际上不需要，因为其数据并不保存在存储介质上，而是动态生成的
    */
    s->s_magic = PROC_SUPER_MAGIC;
    /*
    proc_sops中保存了对超级块的各个操作，其中收集了内核管理proc文件所需的各个函数
    static const struct super_operations proc_sops =
    {
        .alloc_inode    = proc_alloc_inode,
        .destroy_inode    = proc_destroy_inode,
        .drop_inode    = generic_delete_inode,
        .delete_inode    = proc_delete_inode,
        .statfs        = simple_statfs,
    };
    */
    s->s_op = &proc_sops;
    s->s_time_gran = 1;

    //为proc的根目录创建一个inode
    de_get(&proc_root);
    /*
    struct proc_dir_entry proc_root =
    {
        .low_ino    = PROC_ROOT_INO,
        .namelen    = 5,
        .name        = "/proc",
        .mode        = S_IFDIR | S_IRUGO | S_IXUGO,
        .nlink        = 2,
        .count        = ATOMIC_INIT(1),
        .proc_iops    = &proc_root_inode_operations,
        .proc_fops    = &proc_root_operations,
        .parent        = &proc_root,
    };
    */
    root_inode = proc_get_inode(s, PROC_ROOT_INO, &proc_root);
    if (!root_inode)
        goto out_no_root;
    root_inode->i_uid = 0;
    root_inode->i_gid = 0;
    //使用d_alloc_root将其转换为一个dentry，加入到超级块中，用作文件系统中查找操作的起点
    s->s_root = d_alloc_root(root_inode);
    if (!s->s_root)
        goto out_no_root;
    return 0;

out_no_root:
    printk("proc_read_super: get root inode failed\n");
    iput(root_inode);
    de_put(&proc_root);
    return -ENOMEM;
}

proc文件系统中，根inode与其他inode的不同之处在于，它不仅包含"普通"的文件和目录(都是动态生成的)，还管理者特定于进程的PID目录，其中包含了各个系统进程的详细信息，因而，根inode需要有自身的inode操作和文件操作
\linux-2.6.32.63\fs\proc\root.c

/*
 * The root /proc directory is special, as it has the
 * <pid> directories. Thus we don‘t use the generic
 * directory handling functions for that..
 */
static const struct file_operations proc_root_operations = {
    .read         = generic_read_dir,
    .readdir     = proc_root_readdir,
};

/*
 * proc root can do almost nothing..
 */
static const struct inode_operations proc_root_inode_operations = {
    .lookup        = proc_root_lookup,
    .getattr    = proc_root_getattr,
};

generic_read_dir是一个标准的虚拟文件系统函数，该目录不能像普通文件那样处理，不能直接从中读取数据，需要使用proc_root_lookup
0x5: 管理/proc数据项

在proc文件系统投入使用之前，必须向其中添加数据项，内核提供了几个辅助例程来添加文件、创建目录等，使得内核的其他部分能够尽可能容易地完成相关的任务

1. 数据项的创建和注册

新数据项分为两个步骤添加到proc文件系统

1. 创建proc_dir_entry的一个新实例，填充描述该数据项的所有需要的信息
2. 将该实例注册到proc的数据结构，使得外部能够看到该数据项
//因为这两个步骤从来不会独立执行，因此内核提供了辅助函数create_proc_entry用于合并这两个操作

\linux-2.6.32.63\include\linux\proc_fs.h

/*
1. name: 指定了文件名
2. mode: 按传统的UNIX方案(用户/组/其他)指定了访问权限
3. parent: 一个指针，指向该文件父目录的proc_dir_entry实例
*/
extern struct proc_dir_entry *create_proc_entry(const char *name, mode_t mode, truct proc_dir_entry *parent);

需要明白的是，该函数只填充了proc_dir_entry结构的一些必要的成员，因此必须对产生的结构进行一些手工校正

struct proc_dir_entry *entry = NULL;
entry = create_proc_entry("hyperCard", S_IREG | S_IRUGO | S_IWUSR, %proc_net);

if(!entry)
{
    printk(KERN_ERR "unable to cteate /proc/net/hyperCard\n");
    return -EIO;
}
else
{
    entry->read_proc = hypercard_proc_read;
    entry->write_proc = hypercard_proc_write;
}

在创建了数据项之后，使用fs/proc/generic.c中的proc_register将其注册到proc文件系统，该任务划分为3个步骤

1. 生成一个唯一的proc内部编号，向数据项赋予身份，get_inode_number返回一个未使用的编号，用于为动态生成的数据项
2. 必须适当地设置proc_dir_entry实例的next、parent成员。将新数据项集成到proc文件系统的层次结构中
3. 如果此前proc_dir_entry的成员proc_iops、proc_fops为NULL指针，那么需要根据文件类型，适当地设置指向file_operations和inode_operatoins结构实例的指针，否则使用原值即可

\linux-2.6.32.63\fs\proc\generic.c

static int proc_register(struct proc_dir_entry * dir, struct proc_dir_entry * dp)
{
    unsigned int i;
    struct proc_dir_entry *tmp;

    i = get_inode_number();
    if (i == 0)
        return -EAGAIN;
    dp->low_ino = i;

    //proc目录使用的结构如下
    if (S_ISDIR(dp->mode))
    {
        if (dp->proc_iops == NULL)
        {
            dp->proc_fops = &proc_dir_operations;
            dp->proc_iops = &proc_dir_inode_operations;
        }
        dir->nlink++;
    }
    //对符号链接只需要inode_operations，不需要file_operations
    else if (S_ISLNK(dp->mode))
    {
        if (dp->proc_iops == NULL)
            dp->proc_iops = &proc_link_inode_operations;
    }
    //对于普通文件，内核使用proc_file_operations、proc_file_inode_operations来定义文件和inode‘的操作方法’
    else if (S_ISREG(dp->mode))
    {
        if (dp->proc_fops == NULL)
            dp->proc_fops = &proc_file_operations;
        if (dp->proc_iops == NULL)
            dp->proc_iops = &proc_file_inode_operations;
    }

    spin_lock(&proc_subdir_lock);

    for (tmp = dir->subdir; tmp; tmp = tmp->next)
        if (strcmp(tmp->name, dp->name) == 0) {
            WARN(1, KERN_WARNING "proc_dir_entry ‘%s/%s‘ already registered\n",
                dir->name, dp->name);
            break;
        }

    dp->next = dir->subdir;
    dp->parent = dir;
    dir->subdir = dp;
    spin_unlock(&proc_subdir_lock);

    return 0;
}

2. 查找proc数据项

用户空间应用程序访问proc文件时，就像是访问常规文件系统中的普通文件一样，和VFS例程一样，查找过程将在一定时间达到real_lookup。该函数将调用inode_operations的lookup函数指针，根据文件名的各个路径分量，来确定文件名所对应的inode
对proc数据项的搜索从proc文件系统的装载点开始，通常是/proc，对应于proc根目录独有的file_operations的lookup指针，其指向proc_root_lookup，在将实际工作委托给具体的例程之前，内核使用该例程来区分两种不同类型的proc数据项

1. 数据项可能是某个特定于进程的目录中的文件，例如: /proc/1/maps
2. 数据项也可能是驱动程序、子系统动态注册的文件，例如: /proc/cpuinfo
//内核需要区分这两种文件

0x6: 读取和写入信息

内核使用保存在proc_file_operations中的操作来读写常规proc数据项的内容
\linux-2.6.32.63\fs\proc\generic.c

static const struct file_operations proc_file_operations =
{
    .llseek        = proc_file_lseek,
    .read        = proc_file_read,
    .write        = proc_file_write,
};

1. proc_file_read的实现

从proc文件读取数据的操作分为3个步骤

1. 分配一个内核内存页面，产生的数据将填充到页面中
2. 调用一个特定于文件的函数，向内核内存页面填充数据
//第二步是最重要的，必须为此准备好子系统的数据和内核中的数据结构
3. 数据丛内核空间复制到用户空间

\linux-2.6.32.63\fs\proc\generic.c

static ssize_t proc_file_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
{
    struct proc_dir_entry *pde = PDE(file->f_path.dentry->d_inode);
    ssize_t rv = -EIO;

    spin_lock(&pde->pde_unload_lock);
    if (!pde->proc_fops)
    {
        spin_unlock(&pde->pde_unload_lock);
        return rv;
    }
    pde->pde_users++;
    spin_unlock(&pde->pde_unload_lock);

    rv = __proc_file_read(file, buf, nbytes, ppos);

    pde_users_dec(pde);
    return rv;
}

2. proc_file_write的实现

向proc文件写入数据和向普通文件写入数据是一样的
\linux-2.6.32.63\fs\proc\generic.c

static ssize_t proc_file_write(struct file *file, const char __user *buffer, size_t count, loff_t *ppos)
{
    //PDE函数用于从VFS inode使用container_of机制获取所需的proc_dir_entry实例
    struct proc_dir_entry *pde = PDE(file->f_path.dentry->d_inode);
    ssize_t rv = -EIO;

    if (pde->write_proc)
    {
        spin_lock(&pde->pde_unload_lock);
        if (!pde->proc_fops)
        {
            spin_unlock(&pde->pde_unload_lock);
            return rv;
        }
        pde->pde_users++;
        spin_unlock(&pde->pde_unload_lock);

        /* FIXME: does this routine need ppos?  probably... */
        /*
        proc_write的实现通常会执行下列操作
        1. 必须检查用户输入的长度，确保不超出所分配区域的长度
        2. 数据从用户空间复制到分配的内核空间区域
        3. 从字符串中提取出信息，该操作称之为解析(parsing)
        4. 根据收到的用户信息，对该子系统进行操作
        */
        rv = pde->write_proc(file, buffer, count, pde->data);
        pde_users_dec(pde);
    }
    return rv;
}

0x7: 进程相关的信息

输出与系统进程相关的详细信息，是proc文件系统最初设计的主要任务之一，proc_pid_lookup负责打开/proc/<pid>中特定于PID的文件
\linux-2.6.32.63\fs\proc\base.c

该例程的目的在于，创建一个inode作为第一个对象，用于后续的特定于PID的操作，该inode表示了/proc/pid目录，其中包含了所有能够提供特定于进程的信息的文件，我们下面分两种情况分别讨论

1. self目录

虽然可以明确的根据进程PID来选择进程，但当前运行进程的数据也可以通过/proc/self目录即可获取，无需提供PID，内核会自动判断当前运行的进程
self目录实现为一个指定特定于PID目录的符号链接，因而，相关的inode的结构总是相同的，并不包含所引用的进程的任何信息，在读取链接的目标时，将动态获取相关进程的信息，接下来，间剩余的工作委托给标准的虚拟文件系统函数，即负责将查找操作引导到准确的位置上
2. 根据pid进行选择

如果将一个PID而不是self传递到proc_pid_lookup，那么查找过程如下

1) 创建目录inode

\linux-2.6.32.63\fs\proc\base.c

struct dentry *proc_pid_lookup(struct inode *dir, struct dentry * dentry, struct nameidata *nd)
{
    struct dentry *result = ERR_PTR(-ENOENT);
    struct task_struct *task;
    unsigned tgid;
    struct pid_namespace *ns;

    result = proc_base_lookup(dir, dentry);
    if (!IS_ERR(result) || PTR_ERR(result) != -ENOENT)
        goto out;

    //因为文件名总是字符串形式的，而PID是整数，内核必须使用name_to_int辅助函数进行相应的转换，将由数字组成的字符串转换为整数
    tgid = name_to_int(dentry);
    if (tgid == ~0U)
        goto out;

    ns = dentry->d_sb->s_fs_info;
    rcu_read_lock();
    //根据pid获取对应进程的task_struct
    task = find_task_by_pid_ns(tgid, ns);
    if (task)
        get_task_struct(task);
    rcu_read_unlock();
    if (!task)
        goto out;

    /*
    在找到目标进程的task_struct之后，内核将剩余的大部分工作委托给fs/proc/base.c中实现的proc_pid_instantiate函数，该函数又依赖于proc_pid_make_inode
    1. 首先，通过VFS的标准函数new_inode创建一个新的ionde
    2. 这在本质上会归结到特定于proc文件系统的proc_alloc_inode例程，该例程利用自身的slab缓存创建了一个proc_inode结构实例
    3. 在调用proc_pid_make_indoe之后，proc_pid_instantiate中剩余的代码只需要执行几项管理任务，其中最重要的是将inode操作inode->i_op设置为指向proc_tgid_base_inode_operations
    */
    result = proc_pid_instantiate(dir, dentry, task, NULL);
    put_task_struct(task);
out:
    return result;
}

2) 处理文件

在特定于PID的目录/proc/pid中处理一个文件(目录)时，是通过使用该目录的inode操作完成的，我们在讨论虚拟文件系统机制时知道，内核使用静态定义的proc_base_inode_operations结构作为PID inode的inode_operations实例
0x8: 系统控制机制

可以在运行时通过"系统控制"修改内核行为，控制参数从用户空间传输到内核后，无须重启机器，操纵内核行为的传统方法是sysctl系统调用，但是不同于系统调用，不存在POSIX或者其他任何标准来定义一个标准的sysctl集合，使得所有兼容系统都实现该集合，这导致sysctl现在已经很少使用
为解决这种情况，Linux借助于proc文件系统，内核重排了所有的sysctl，建立起一个层次结构，并导出到/proc/sys目录下，可以使用简单的用户空间工具来读取和操纵这些参数，如果需要修改内核的运行时行为，cat、echo就足够了

1. 使用sysctl

每个类UNIX操作系统中的许多sysctl，都组织为一个明确的层次结构，反映了文件系统中所使用的树形结构，也正是因为这种特性，才使得sysctl能够很简单地通过一个虚拟文件系统导出
但与文件系统相比，sysctl不使用字符串表示路径分量，相反，sysctl使用"符号常数整数"来表示路径分量，与字符串形式的路径名相比，内核更容易解析这种格式
内核提供了几个"基本类型"，包括

1. CTL_DEV: 外设有关信息
    1) DEV_PARPORT
    2) DEV_CDROM: 提供有关系统中的光驱的信息
        2.1) DEV_CDROM_INFO: 提供了有关驱动器能力的一般信息
        2.2) DEV_CDROM_AUTOCLOSE
        2.3) DEV_CDROM_CHECK_MEDIA
2. CTL_NET
    1) NET_CORE
        1.1) NET_CORE_FASTROUTE
        1.2) NET_CORE_DEVWEIGHT
    2) NET_IPV4
        2.1) NET_IPV4_TVP_FIN_TIMEOUT
        2.2) NET_IPV4_AUTOCONFIG
2. CTL_KERN: 内核本身有关信息
    1) KERN_OSTYPE
    2) KERN_OSRELEASE
    3) KERN_SYSRQ
3. CTL_VM: 内存管理信息和参数
    1) VM_PAGEBUF
    2) VM_SWAPPINESS

代码的核心是定义在C标准库中的sysctl函数
/usr/include/sys/sysctl.h

__BEGIN_DECLS

/*
1. __name: 通过整数数组的形式给出具体的路径，每个数组元素表示一个路径分量
2. __nlen: 啮合并不指定路径有多少个分量，因此必须显示指明
3. __oldval: 一个指针，指向一个类型不确定的内存区，用于返回sysctl的原值
4. __oldlenp: 指定所分配的内存区以字节为单位的长度，在系统调用执行完毕后，输出数据的长度由__oldlenp指定
5. __newval
6. __newlen: __newval、__newlen形成了一对指针和长度的组合，在sysctl允许修改内核参数时，可以使用这两个参数
*/
extern int sysctl (int *__name, int __nlen, void *__oldval, size_t *__oldlenp, void *__newval, size_t __newlen) __THROW;

__END_DECLS

2. 数据结构

内核定义了几个数据结构来管理各个sysctl，各个sysctl是按层次结构排布的，数据结构中不仅包含了各个sysctl及其读写操作的相关信息，还必须提供在各个数据项之间映射层次结构的方
每个sysctl项都有自身的ctl_table实例
\linux-2.6.32.63\include\linux\sysctl.h

struct ctl_table
{
    /*
    Binary ID 二进制ID
    在该sysctl项所在的层次上必须是唯一的，但不不必在整个sysctl表中是唯一的，这和文件系统的概念是一样的
    */
    int ctl_name;            

    /*
    Text ID for /proc/sys, or zero
    /proc/sys下各目录项的文本ID，或NULL
    所有根数据项(即对应于几个基本类别的sysctl)的名称，都表现为/proc/sys下的目录名
    dr-xr-xr-x 2 root root 0 Jun 14 19:43 abi
    dr-xr-xr-x 2 root root 0 Jun 14 19:43 crypto
    dr-xr-xr-x 2 root root 0 Jun 14 19:43 debug
    dr-xr-xr-x 7 root root 0 Jun 14 19:43 dev
    dr-xr-xr-x 6 root root 0 May 22 16:24 fs
    dr-xr-xr-x 5 root root 0 Jun 14 19:43 kernel
    dr-xr-xr-x 6 root root 0 Jun 14 19:43 net
    dr-xr-xr-x 2 root root 0 Jun 14 19:43 vm
    */
    const char *procname;    

    //data可以指定任何值，通常是一个函数指针或字符串，字符串由特定于sysctl的函数处理，通用代码都不会访问该成员
    void *data;

    //maxlen指定了一个sysctl能够接收或输出的数据的最大长度(字节)
    int maxlen;

    //mode控制了对数据的访问权限，即磁盘ACL权限
    mode_t mode;

    /*
    child是一个指针，指向一个数组，各个数组项都是ctl_table实例，这些诶ctl_table实例是当前数据项的子节点，例如
    1. 在CTL_KERN sysctl项中，child指向一个数组，包含的sysctl项是KERN_OSTYPE、KERN_OSRELEASE、KERN_HOSTNAME
    2. 因为这些项在层次上属于CTL_KERN_ sysctl的下一级

    因为ctl_table数组的长度没有显示存储，因而数据的最后一项必须总是NULL指针，标志数组的结束
    */
    struct ctl_table *child;

    /* Automatically set 自动设置 */
    struct ctl_table *parent;    

    /* Callback for text formatting 用于格式化文本的回调函数 */
    proc_handler *proc_handler;    

    /* Callback function for all r/w 用于所有读/写操作的回调函数 */
    ctl_handler *strategy;
    void *extra1;
    void *extra2;
};

内核提供了ctl_table_header数据结构，使得能够将几个sysctl表维护在一个链表中，能够用我们熟悉的标准函数遍历很操作

struct ctl_table_header
{
    struct ctl_table *ctl_table;
    struct list_head ctl_entry;
    int used;
    int count;
    struct completion *unregistering;
    struct ctl_table *ctl_table_arg;
    struct ctl_table_root *root;
    struct ctl_table_set *set;
    struct ctl_table *attached_by;
    struct ctl_table *attached_to;
    struct ctl_table_header *parent;
};

系统的各个sysctl表之间的层次关系，通过ctl_tables的child成员和使用ctl_table_header实现的链表建立起来，通过child建立的关联，使得各个表之间可以建立一种直接的联系，而这种联系又反映出了sysctl的层次结构
3. 静态的sysctl表

对所有的sysctl都定义了静态的sysctl表，无论系统配置如何，根节点对应的表root_table，用作所有静态定义的数据的根
\linux-2.6.32.63\kernel\sysctl.c

static struct ctl_table root_table[];
static struct ctl_table_root sysctl_table_root;
static struct ctl_table_header root_table_header =
{
    .count = 1,
    .ctl_table = root_table,
    .ctl_entry = LIST_HEAD_INIT(sysctl_table_root.default_set.list),
    .root = &sysctl_table_root,
    .set = &sysctl_table_root.default_set,
};
static struct ctl_table_root sysctl_table_root =
{
    .root_list = LIST_HEAD_INIT(sysctl_table_root.root_list),
    .default_set.list = LIST_HEAD_INIT(root_table_header.ctl_entry),
};

针对该表，也同样构建了一个ctl_table_header数据项，以便将附加的层次结构维护到一个链表中，这些可以与root_table定义的层次结构叠加，root_table表定义了对各种sysctl进行分类的框架

static struct ctl_table root_table[] = {
    {
        .ctl_name    = CTL_KERN,
        .procname    = "kernel",
        .mode        = 0555,
        .child        = kern_table,
    },
    {
        .ctl_name    = CTL_VM,
        .procname    = "vm",
        .mode        = 0555,
        .child        = vm_table,
    },
    {
        .ctl_name    = CTL_FS,
        .procname    = "fs",
        .mode        = 0555,
        .child        = fs_table,
    },
    {
        .ctl_name    = CTL_DEBUG,
        .procname    = "debug",
        .mode        = 0555,
        .child        = debug_table,
    },
    {
        .ctl_name    = CTL_DEV,
        .procname    = "dev",
        .mode        = 0555,
        .child        = dev_table,
    },
/*
 * NOTE: do not add new entries to this table unless you have read
 * Documentation/sysctl/ctl_unnumbered.txt
 */
    { .ctl_name = 0 }
};

4. 注册sysctl

除了静态定义的sysctl之外，内核还提供了一个接口，用于动态注册和注销新的系统控制功能，register_sysctl_table用于注册sysctl表，而其对应的unregister_sysctl_table用于删除sysctl表，通常发生在模块卸载时
注册sysctl项，不会自动地创建将sysctl项关联到proc数据项的inode实例，因为大多数sysctl从来都不通过proc使用，这种做法会带来严重的浪费，相反，与proc文件的关联是动态创建的，在proc文件系统初始化时，只创建了与sysctl相关的目录/proc/sys
\linux-2.6.32.63\fs\proc\proc_sysctl.c

int __init proc_sys_init(void)
{
    struct proc_dir_entry *proc_sys_root;

    proc_sys_root = proc_mkdir("sys", NULL);
    proc_sys_root->proc_iops = &proc_sys_dir_operations;
    proc_sys_root->proc_fops = &proc_sys_dir_file_operations;
    proc_sys_root->nlink = 0;
    return 0;
}

在proc_sys_inode_operations中指定的inode操作确保了/proc/sys下的文件和目录将在需要时动态地创建
5. /proc/sys文件操作

proc_sys_read、proc_sys_write的实现非常类似，两者都需要执行下面3个简单步骤

1. do_proc_sys_lookup: 查找与/proc/sys中文件关联的sysctl表项
2. 不能保证目标sysctl项的所有权限都已经授权，即使root用于也是如此，有些项可能只允许读，而不允许修改，因而需要一个额外的权限检查，由sysctl_perm执行，而proc_sys_read需要读权限，proc_sys_write需要写权限
3. 调用sysctl表项中存储的proc处理程序来完成操作

2. 简单的文件系统

全功能的文件系统很难编写，在达到可用、高效、正确的状态之前，需要投入大量的工作量，如果文件系统负责在磁盘上实际存储数据，那么这是合理的，但文件系统(特别是虚拟文件系统)除了在块设备上存储文件之外，还可用于许多其他目的，这样的文件系统仍然在内核中运行，并需要遵循各种标准方法，文件系统库libfs，包含了实现文件系统所需的几乎所有要素，开发者只需要提供到其数据的一个接口，文件系统就完成了
此外，还有一些以seq_file机制提供的标准例程可用，使得顺序文件的处理变得很简单，同时，开发者可能只是想要向用户空间导出几个值，而不想和现存的文件系统(如proc)打交道，内核对此也提供了一种方案: debugfs文件系统允许之用几个系统调用，就实现一个双向的调试接口

0x1: 顺序文件

在讨论文件系统库之前，我们先来讨论一下顺序文件接口，小的文件系统中的文件，通常用户层是从头到尾顺序读取的。fs/seq_file.c中的例程容许用最小代价来实现此类文件，虽然顺序文件是可以进行定位(seek)操作的，但其实现并不高效。顺序访问，即逐个读取数据项，显然是首选的访问模式
kprobe机制包含了debugfs文件系统的一个接口，一个顺序文件向用户层提供了所有注册的探测器，我们通过讨论kprobe的实现，来说明顺序文件的思想

1. 编写顺序文件处理程序

基本上来说，必须提供一个struct file_operations的实例，其中的一些函数指针指向一些seq_例程，这样就可以利用顺序文件的标准实现了，kprobe子系统的做法如下
\linux-2.6.32.63\kernel\kprobes.c

static const struct seq_operations kprobes_seq_ops =
{
    .start = kprobe_seq_start,
    .next  = kprobe_seq_next,
    .stop  = kprobe_seq_stop,
    .show  = show_kprobe_addr
};

static int __kprobes kprobes_open(struct inode *inode, struct file *filp)
{
    return seq_open(filp, &kprobes_seq_ops);
}

static const struct file_operations debugfs_kprobes_operations =
{
    //唯一需要实现的方法是open，需要将文件关联到顺序文件接口
    .open           = kprobes_open,
    .read           = seq_read,
    .llseek         = seq_lseek,
    .release        = seq_release,
};

seq_open建立顺序文件机制所需的数据结构，我们知道，struct file的private成员可以指向文件私有的任意数据，通用的VFS函数不会访问该数据，seq_open使用该指针建立了与struct seq_file的一个实例之间的关联，struct seq_file中包含了顺序文件的状态信息
\linux-2.6.32.63\include\linux\seq_file.h

struct seq_file
{
    //buf指向一个内存缓冲区，用于构建传输给用户层的数据
    char *buf;

    //size给出了缓冲区中总的字节数
    size_t size;

    //复制操作的起始位置由from指定
    size_t from;

    //count指定了需要传输到用户层的剩余的字节数
    size_t count;

    //index是缓冲区的另一个索引，它标记了内核向缓冲区写入下一个新记录的起始位置
    loff_t index;
    loff_t read_pos;
    u64 version;
    struct mutex lock;

    /*
    指向seq_operations的一个实例，这将通用的顺序文件实现与提供具体文件内容的例程关联起来
    内核需要4个方法，这需要由文件提供者实现
    struct seq_operations
    {
        void * (*start) (struct seq_file *m, loff_t *pos);
        void (*stop) (struct seq_file *m, void *v);
        void * (*next) (struct seq_file *m, void *v, loff_t *pos);
        int (*show) (struct seq_file *m, void *v);
    };
    */
    const struct seq_operations *op;
    void *private;
};

kprobe实现了所有上述的例程，kprobe机制允许向内核中某些位置附加探测器，所有注册的探测器散列到数组kprobe_table中，该数组的长度是静态定义的(即KPROBE_TABLE_SIZE)

//检查当前游标是否超出数组边界
static void __kprobes *kprobe_seq_start(struct seq_file *f, loff_t *pos)
{
    return (*pos < KPROBE_TABLE_SIZE) ? pos : NULL;
}

//将游标移动到下一个位置，并检查索引是否越界
static void __kprobes *kprobe_seq_next(struct seq_file *f, void *v, loff_t *pos)
{
    (*pos)++;
    if (*pos >= KPROBE_TABLE_SIZE)
        return NULL;
    return pos;
}

static void __kprobes kprobe_seq_stop(struct seq_file *f, void *v)
{
    /* Nothing to do */
}

2. 与虚拟文件系统的关联

我们已经了解了顺序文件的用户所需要的每件事情，接下里的事情就是将这些操作关联到虚拟文件系统，该工作留给内核完成

1. 为建立关联，必须像debugfs_kprobes_operations那样，将seq_read赋值给file_operations的read方法，该方法将VFS和顺序文件连接起来
2. 该函数(seq_read)需要从VFS层的struct file获得seq_file实例，seq_open通过private_data建立了该关联
3. 如果有些数据等待写出(如果struct seq_file的count成员为正值)，则使用copy_to_user将其复制到用户层，此外，还需要更新seq_file的各个状态成员
4. 下一步，会产生新的数据，在调用start之后，内核连续调用show、next，直至填满可用的缓冲区，最后调用stop，使用copy_to_user将生成的数据复制到用户空间

0x2: 用libfs编写文件系统

libfs是一个库，提供了几个非常通用的标准例程，可用于创建服务于特定用途的小型文件系统，这些例程很适合于没有后备存储器的内存文件，显 然，libfs的代码无法与特定的磁盘格式交互，这需要由完整的文件系统实现来正确处理，该库的代码包含在一个文件中，即fs/libfs.c
使
用libfs建立的虚拟文件系统，其文件和目录层次结构可使用dentry树产生和遍历，这意味着在该文件系统的声明周期中，所有的dentry都必须驻
留在内存中，除非通过unlink或rmdir显示删除，否则不能消失，这个要求很容易做到，代码只需要保证所有dentry的使用计数都是正值即可
为了深入理解libfs的思想，我们接下来讨论实现目录处理的方法，libfs提供了目录的inode_operations和file_operations的实例模版，任何利用了libfs实现的虚拟文件系统都可以重用
\linux-2.6.32.63\fs\libfs.c

const struct file_operations simple_dir_operations =
{
    .open        = dcache_dir_open,
    .release    = dcache_dir_close,
    .llseek        = dcache_dir_lseek,
    .read        = generic_read_dir,
    .readdir    = dcache_readdir,
    .fsync        = simple_sync_file,
};

const struct inode_operations simple_dir_inode_operations = {
    .lookup        = simple_lookup,
};

static const struct super_operations simple_super_operations = {
    .statfs        = simple_statfs,
};

如果一个虚拟文件系统建立了正确的dentry树，那么将simple_dir_operations和simple_dir_inode_operations分别设置为目录的文件操作和inode操作即可。libfs提供的函数可以确保树中包含的信息可以通过像getdents之类的标准系统调用导出到用户层
我们接下来讨论向虚拟文件系统添加文件的方式，debugfs文件系统即采用了libfs，新的文件(也即新的inode)用下列例程创建，因为对于基于libfs的虚拟文件系统来说，新文件也是一个虚拟的概念
\linux-2.6.32.63\fs\debugfs\inode.c

static struct inode *debugfs_get_inode(struct super_block *sb, int mode, dev_t dev, void *data, const struct file_operations *fops)
{
    //分配一个新的struct inode实例
    struct inode *inode = new_inode(sb);

    if (inode)
    {
        inode->i_mode = mode;
        inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
        //根据访问权限信息判断将什么文件操作和inode操作关联到该文件
        switch (mode & S_IFMT)
        {
        default:
            //对于设备文件，使用标准例程init_special_inode(不予libfs关联)
            init_special_inode(inode, mode, dev);
            break;
        case S_IFREG:
            /*
            普通文件不能使用libfs的file_operations模版，至少需要手工指定read、write、open方法，这是必须的
            1. read: 负责从内核内存准备数据并复制到用户空间
            2. write: 用于读取用户的输出并以一定的方法应用它
            这就是实现定义的文件系统所需的全部工作
            */
            inode->i_fop = fops ? fops : &debugfs_file_operations;
            inode->i_private = data;
            break;
        case S_IFLNK:
            inode->i_op = &debugfs_link_operations;
            inode->i_fop = fops;
            inode->i_private = data;
            break;
        case S_IFDIR:
            //目录需要的是libfs提供的标准文件操作和inode操作，这确保了不需要其他工作就可以正确地处理新目录
            inode->i_op = &simple_dir_inode_operations;
            inode->i_fop = fops ? fops : &simple_dir_operations;
            inode->i_private = data;

            /* directory inodes start off with i_nlink == 2
             * (for "." entry) */
            inc_nlink(inode);
            break;
        }
    }
    return inode;
}

文件系统还需要一个超级块，libfs提供了simple_fill_super方法，可用于填充给出的超级块

0x3: 调试文件系统

使用了libfs函数的一个特别的文件系统是调试文件系统debugfs，它向内核开发者提供了一种向用户层提供信息的可能方法，仅当内核编译时启用了DEBUG_FS配置选项，才会激活对debugfs的支持，因而向debugfs注册文件的代码，都会被C预处理器语句包围，来检查CONFIG_DEBUG_FS

1. 示例

\linux-2.6.32.63\kernel\kprobes.c

static int __kprobes debugfs_kprobe_init(void)
{
    struct dentry *dir, *file;
    unsigned int value = 1;

    //debugfs_create_dir用于创建一个新目录
    dir = debugfs_create_dir("kprobes", NULL);
    if (!dir)
        return -ENOMEM;

    //debugfs_create_file用于在目录中创建一个新文件
    file = debugfs_create_file("list", 0444, dir, NULL,
                &debugfs_kprobes_operations);
    if (!file) {
        debugfs_remove(dir);
        return -ENOMEM;
    }

    file = debugfs_create_file("enabled", 0600, dir,
                    &value, &fops_kp);
    if (!file) {
        debugfs_remove(dir);
        return -ENOMEM;
    }

    return 0;
}

之前讨论顺序文件机制时，我们曾经讨论过debugfs_kprobes_operations
2. 编程接口

debugfs代码非常简单、干净，我们可以学习它的源代码，这是对libfs例程的非常好的应用，有3个函数可用于创建新的文件系统对象
\linux-2.6.32.63\include\linux\debugfs.h

//普通文件
struct dentry *debugfs_create_file(const char *name, mode_t mode, struct dentry *parent, void *data, const struct file_operations *fops);

//目录
struct dentry *debugfs_create_dir(const char *name, struct dentry *parent);

//符号链接
struct dentry *debugfs_create_symlink(const char *name, struct dentry *parent, const char *dest);

//删除
void debugfs_remove(struct dentry *dentry);
void debugfs_remove_recursive(struct dentry *dentry);

//重命名
struct dentry *debugfs_rename(struct dentry *old_dir, struct dentry *old_dentry, struct dentry *new_dir, const char *new_name);

0x4: 伪文件系统

我们知道，内核支持伪文件系统，其中收集了一些相关的inode，但不能装载，因而对用户层也黑丝不可见的，libfs也提供了一个辅助函数，来实现这种特殊类型的文件系统
内核使用了一个伪文件系统来跟踪表示块设备的所有inode
\linux-2.6.32.63\fs\block_dev.c

static int bd_get_sb(struct file_system_type *fs_type, int flags, const char *dev_name, void *data, struct vfsmount *mnt)
{
    //get_sb_pseudo方法可以确保不能从用户空间装载该文件系统，这需要设置MS_NOUSER标志，还填充了一个struct super_block实例，并分配了伪文件系统根目录的inode
    return get_sb_pseudo(fs_type, "bdev:", &bdev_sops, 0x62646576, mnt);
}

static struct file_system_type bd_type =
{
    .name        = "bdev",
    .get_sb        = bd_get_sb,
    .kill_sb    = kill_anon_super,
};

为使用伪文件系统，内核需要使用kern_mount或kern_mount_data装载它，它可以用于收集inode，而无需写一个专门的数据结构，对于bdev，所有表示块设备的inode都群集起来，但该集合只能从内核看到，用户空间无法看到

3. sysfs

sysfs是一个向用户空间导出内核对象的文件系统，它不仅提供了查看内核内部数据结构的能力，还可以修改这些数据结构。特别重要的是，该文件系统高度层次化的组织: sysfs的数据项来源于内核对象(kobject)，而内核对象的层次化组织直接反映到了sysfs的目录布局中
在很多情况下，使用了简短、易读的文本串来懂啊出对象的属性，但通过sysfs与内核传递二进制数据的方法来被频繁采用，sysfs已经成为老式的IOCTL机制的一种替代品

0x1: 概述

1. kobject包含在一个层次化的组织中，最重要的一点是，它们可以有一个父对象，可以包含到一个kset中，这决定了kobject出现在sysfs层次结构中的位置
    1) 如果存在父对象，那么需要在父对象对应的目录中新建一项
    2) 否则，将其防止到kobject所在kset所属的kobject对应的目录中
2. 每个kobject在sysfs中都表示为一个目录，出现在该目录中的文件是对象的属性，用户导出和设置属性的操作由对象所属的子系统提供
3. 总线、设备、驱动程序和类是使用kobject机制的主要内核对象，因而也占据了sysfs中几乎所有的数据项

0x2: 数据结构

我们先来讨论sysfs实现所用的数据结构

1. 目录项

目录项由<sysfs.h>中定义的struct sysfs_dirent表示，它是sysfs的主要数据结构，整个实现都围绕它进行，每个sysfs结点都表示为sysfs_dirent的一个实例
Linux/fs/sysfs/sysfs.h

struct sysfs_dirent
{
    atomic_t        s_count;
    atomic_t        s_active;
    struct sysfs_dirent    *s_parent;

    //s_sibling用于捕获数据结构中各sysfs数据项之间的父子关系
    struct sysfs_dirent    *s_sibling;

    //s_name表示文件、目录、符号链接的名称
    const char        *s_name;

    union {
        struct sysfs_elem_dir        s_dir;
        struct sysfs_elem_symlink    s_symlink;
        struct sysfs_elem_attr        s_attr;
        struct sysfs_elem_bin_attr    s_bin_attr;
    };

    /*
    内核使用s_flags有两方面的目的
    1. 用来设置sysfs数据项的类型
    2. 设置若干标志
        1) 低8位用作类型: 可以用辅助函数sysfs_type访问
            1.1) SYSFS_DIR: 目录
            1.2) SYSFS_KOBJ_ATTR: 普通属性
            1.3) SYS_KOBJ_BIN_ATTR: 二进制属性
            1.4) SYS_KOBJ_LINK: 符号链接
        2) 剩余比特用作标志位:
            2.1) SYSFS_FLAG_REMOVED: 正在删除某个sysfs数据项
    */
    unsigned int        s_flags;
    ino_t            s_ino;

    //与sysfs_dirent实例相关的目录项的访问权限信息保存在s_mode中
    umode_t            s_mode;
    struct sysfs_inode_attrs *s_iattr;
};

与任何其他的文件系统类似，sysfs数据项也由struct dentry实例表示，两种层次的表示之间，通过dentry->d_fsdata建立关联，该成员指向与dentry实现相关的sysfs_dirent实例

2. 属性

我们接下来讨论表示属性的数据结构，以及用于声明新属性的机制，P552

0x3: 装载文件系统

0x4: 文件和目录操作

0x5: 向sysfs添加内容

undone

Copyright (c) 2015 LittleHann All rights reserved