虚拟文件系统用来处理与linux标准文件系统相关的所有系统调用，他能为各种文件提供一种接口。
VFS所隐含的思想主要是：引入一种普通文件模型，这个模型能够表示支持的所有的文件；VFS为底层提供了抽象即 1、提供了一个最小的通用模型，使得这个模型的功能时所有的文件系统的最小集。 2、提供一个尽量大的通用模型，使得这个模型包含所有文件系统功能的合集。
通用文件模型包含以下几个模块：
超级块对象 存放已安装文件系统的有关信息
索引节点对象 存放具体文件的一般信息
文件对象 存放打开文件与进程之间进行交互的有关信息。
目录项对象 存放目录项(也就是文件的特定名称)与对应文件进行连接的有关信息。
最近使用的目录项对象都存在所谓的目录项高速缓的磁盘高速缓存中，以加快从文件名到最后一个路径分量的索引节点的转换过程。
磁盘高速缓存属于软件机制；允许内核将原本存在磁盘上的某些信息保存在RAM中，以便能对这些数据进行快速访问；
VFS时应用程序和具体文件之间的一层，不过在某些情况下有些操作可以由VFS本身去执行，无需调用底层函数file_operation；比如close一个已经打开的文件时，bing
不需要涉及磁盘上的相应文件，只需要VFS释放对应的文件对象。
VFS 数据结构：
超级块对象：
struct super_block {
struct list_head s_list; /* Keep this first */
dev_t s_dev; /* search index; _not_ kdev_t */
unsigned char s_blocksize_bits;
unsigned long s_blocksize;
loff_t s_maxbytes; /* Max file size */
struct file_system_type *s_type;
const struct super_operations *s_op;
const struct dquot_operations *dq_op;
const struct quotactl_ops *s_qcop;
const struct export_operations *s_export_op;
unsigned long s_flags;
unsigned long s_magic;
struct dentry *s_root;
struct rw_semaphore s_umount;
struct mutex s_lock;
int s_count;
atomic_t s_active;
#ifdef CONFIG_SECURITY
void *s_security;
#endif
const struct xattr_handler **s_xattr;
struct list_head s_inodes; /* all inodes */
struct hlist_bl_head s_anon; /* anonymous dentries for (nfs) exporting */
#ifdef CONFIG_SMP
struct list_head __percpu *s_files;
#else
struct list_head s_files;
#endif
struct list_head s_mounts; /* list of mounts; _not_ for fs use */
/* s_dentry_lru, s_nr_dentry_unused protected by dcache.c lru locks */
struct list_head s_dentry_lru; /* unused dentry lru */
int s_nr_dentry_unused; /* # of dentry on lru */
/* s_inode_lru_lock protects s_inode_lru and s_nr_inodes_unused */
spinlock_t s_inode_lru_lock ____cacheline_aligned_in_smp;
struct list_head s_inode_lru; /* unused inode lru */
int s_nr_inodes_unused; /* # of inodes on lru */
struct block_device *s_bdev;
struct backing_dev_info *s_bdi;
struct mtd_info *s_mtd;
struct hlist_node s_instances;
struct quota_info s_dquot; /* Diskquota specific options */
struct sb_writers s_writers;
char s_id[32]; /* Informational name */
u8 s_uuid[16]; /* UUID */
void *s_fs_info; /* Filesystem private info */
unsigned int s_max_links;
fmode_t s_mode;
/* Granularity of c/m/atime in ns.
Cannot be worse than a second */
u32 s_time_gran;
/*
* The next field is for VFS *only*. No filesystems have any business
* even looking at it. You had been warned.
*/
struct mutex s_vfs_rename_mutex; /* Kludge */
/*
* Filesystem subtype. If non-empty the filesystem type field
* in /proc/mounts will be "type.subtype"
*/
char *s_subtype;
/*
* Saved mount options for lazy filesystems using
* generic_show_options()
*/
char __rcu *s_options;
const struct dentry_operations *s_d_op; /* default d_op for dentries */
/*
* Saved pool identifier for cleancache (-1 means none)
*/
int cleancache_poolid;
struct shrinker s_shrink; /* per-sb shrinker handle */
/* Number of inodes with nlink == 0 but still referenced */
atomic_long_t s_remove_count;
/* Being remounted read-only */
int s_readonly_remount;
};
命名空间：
安装普通文件系统：
mount 系统调用：
sys_mount函数分析如下；
SYSCALL_DEFINE5(mount, char __user *, dev_name, char __user *, dir_name,
char __user *, type, unsigned long, flags, void __user *, data)
{
int ret;
char *kernel_type;
char *kernel_dir;
char *kernel_dev;
unsigned long data_page;
ret = copy_mount_string(type, &kernel_type);
if (ret < 0)
goto out_type;
kernel_dir = getname(dir_name);
if (IS_ERR(kernel_dir)) {
ret = PTR_ERR(kernel_dir);
goto out_dir;
}
ret = copy_mount_string(dev_name, &kernel_dev);
if (ret < 0)
goto out_dev;
ret = copy_mount_options(data, &data_page);
if (ret < 0)
goto out_data;
ret = do_mount(kernel_dev, kernel_dir, kernel_type, flags,
(void *) data_page);
free_page(data_page);
out_data:
kfree(kernel_dev);
out_dev:
putname(kernel_dir);
out_dir:
kfree(kernel_type);
out_type:
return ret;
}
为什么存在copy用户参数到内核地址？ 原因和为什么有copy_from_user（）等函数存在一样的原因。
因为： copy_from_user 函数的目的是从用户空间拷贝数据到内核空间，失败返回没有 被拷贝的字节数，成功返回 0.这个函数含盖了许多关于内核方面的知识,比如内核关于异常出错 的处理.从用户空间拷贝 数据到内核中时必须非常小心,如果用户空间的数据地址是个非法的地址、超出用户空间的范围，或者 那些地址还没有被映射到，都可能对内核产生很大的影响，如 oops，或者被造 成系统安全的影响.所以 copy_from_user 函数的功能就不只是从用户空间拷贝数据那样简单了，它还要 做一些指针检查以及处理这些 问题的方法
转债自http://blog.chinaunix.net/uid-23769728-id-3189280.html
最近貌似有人问为什么要用copy_from_user这类函数的问题，难道内核不能使用用户态的指针吗？那人自己做了个实验，不用copy_from_user，而是直接在内核里使用用户态指针，程序运行得好好的，啥事也没有。那么内核干嘛还要提供这么些函数呢？
我看网上有人说用户态指针在内核里没有意义了，如同内核指针在用户态一样没有意义了。这话其实不对，以x86来说，页目录表是放在CR3中的，这个寄存器 没有什么内核态用户态之分，换句话说一个用户态进程通过系统调用进入内核态，task_struct结构中的cr3都是不变的，没有页目录表变化的情况发 生。所以内核态使用用户进程传递过来的指针是有意义的，而且在用户态下内核的指针也是有意义的，只不过因为权限不够，用户进程使用内核指针就有异常发生。
回到上面的话题，既然内核可以使用用户进程传递过来的指针，那干吗不使用memcpy呢？绝大多数情况下使用memcpy取代 copy_from_user都是OK的，事实上在没有MMU的体系上，copy_from_user就是memcpy。但是为什么有MMU就不一样了 呢，使用copy_from_user除了那个access_ok检查之外，它的实现前半部分就是memcpy，后边多了个两个section。这话要得 从内核提供的缺页异常说起，而且copy_from_user就是用来对付用户态的指针所指向的虚拟地址没有映射到实际物理内存这种情况，这个现象在用户 空间不是什么大事，缺页异常会自动提交物理内存，之后发生异常的指令正常运行，彷佛啥事也没发生。但是这事放到内核里就不一样了，内核需要显式地去修正这 个异常，背后的思想是：内核对于没有提交物理地址的虚拟地址空间的访问不能象用户进程那样若无其事，内核得表明下态度--别想干坏事，老子盯着你呢。就这 么个意思。所以copy_from_user和memcpy的区别就是多了两个section，这样对于缺页的异常，copy_from_user可以修 正，但是memcpy不行。
- #define USER(x...) \
- 9999: x; \
- .section __ex_table,"a"; \
- .align 3; \
- .long 9999b,9001f; \
- .previous
- .long 9999b,9001f;
malloc是先分配虚拟空间，用到的时候才映射物理地址。这正好满足我们的要求，结果不是 很理想，我不知道这个malloc到底内核是不是有类似copy-on-write这样大的特性，总之memcpy对这种情况没有报任何异常。那就干脆来 狠的，直接估摸着一个可能还没被映射的用户空间的虚地址，传递给了内核空间的驱动程序，于是问题来了：memcpy发生了 oops，copy_from_user正常运行了。
看来两者之间就这点区别了，至于access_ok，看过源码的人都知道那不过是验证一下地址范围而已，我开始还以为这个函数会操作页目录表，事实上完全不是。
扫一扫
915
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
