linux驱动开发记录

inode:

include/linux/fs.h

 1 /*
 2  * Keep mostly read-only and often accessed (especially for
 3  * the RCU path lookup and ‘stat‘ data) fields at the beginning
 4  * of the ‘struct inode‘
 5  */
 6 struct inode {
 7     umode_t            i_mode;
 8     unsigned short        i_opflags;
 9     kuid_t            i_uid;
10     kgid_t            i_gid;
11     unsigned int        i_flags;
12
13 #ifdef CONFIG_FS_POSIX_ACL
14     struct posix_acl    *i_acl;
15     struct posix_acl    *i_default_acl;
16 #endif
17
18     const struct inode_operations    *i_op;
19     struct super_block    *i_sb;
20     struct address_space    *i_mapping;
21
22 #ifdef CONFIG_SECURITY
23     void            *i_security;
24 #endif
25
26     /* Stat data, not accessed from path walking */
27     unsigned long        i_ino;
28     /*
29      * Filesystems may only read i_nlink directly.  They shall use the
30      * following functions for modification:
31      *
32      *    (set|clear|inc|drop)_nlink
33      *    inode_(inc|dec)_link_count
34      */
35     union {
36         const unsigned int i_nlink;
37         unsigned int __i_nlink;
38     };
39     dev_t            i_rdev;
40     loff_t            i_size;
41     struct timespec        i_atime;
42     struct timespec        i_mtime;
43     struct timespec        i_ctime;
44     spinlock_t        i_lock;    /* i_blocks, i_bytes, maybe i_size */
45     unsigned short          i_bytes;
46     unsigned int        i_blkbits;
47     blkcnt_t        i_blocks;
48
49 #ifdef __NEED_I_SIZE_ORDERED
50     seqcount_t        i_size_seqcount;
51 #endif
52
53     /* Misc */
54     unsigned long        i_state;
55     struct mutex        i_mutex;
56
57     unsigned long        dirtied_when;    /* jiffies of first dirtying */
58
59     struct hlist_node    i_hash;
60     struct list_head    i_wb_list;    /* backing dev IO list */
61     struct list_head    i_lru;        /* inode LRU list */
62     struct list_head    i_sb_list;
63     union {
64         struct hlist_head    i_dentry;
65         struct rcu_head        i_rcu;
66     };
67     u64            i_version;
68     atomic_t        i_count;
69     atomic_t        i_dio_count;
70     atomic_t        i_writecount;
71 #ifdef CONFIG_IMA
72     atomic_t        i_readcount; /* struct files open RO */
73 #endif
74     const struct file_operations    *i_fop;    /* former ->i_op->default_file_ops */
75     struct file_lock_context    *i_flctx;
76     struct address_space    i_data;
77     struct list_head    i_devices;
78     union {
79         struct pipe_inode_info    *i_pipe;
80         struct block_device    *i_bdev;
81         struct cdev        *i_cdev;
82     };
83
84     __u32            i_generation;
85
86 #ifdef CONFIG_FSNOTIFY
87     __u32            i_fsnotify_mask; /* all events this inode cares about */
88     struct hlist_head    i_fsnotify_marks;
89 #endif
90
91     void            *i_private; /* fs or device private pointer */
92 };

file:

include/linux/fs.h

 1 struct file {
 2     union {
 3         struct llist_node    fu_llist;
 4         struct rcu_head     fu_rcuhead;
 5     } f_u;
 6     struct path        f_path;
 7     struct inode        *f_inode;    /* cached value */
 8     const struct file_operations    *f_op;
 9
10     /*
11      * Protects f_ep_links, f_flags.
12      * Must not be taken from IRQ context.
13      */
14     spinlock_t        f_lock;
15     atomic_long_t        f_count;
16     unsigned int         f_flags;
17     fmode_t            f_mode;
18     struct mutex        f_pos_lock;
19     loff_t            f_pos;
20     struct fown_struct    f_owner;
21     const struct cred    *f_cred;
22     struct file_ra_state    f_ra;
23
24     u64            f_version;
25 #ifdef CONFIG_SECURITY
26     void            *f_security;
27 #endif
28     /* needed for tty driver, and maybe others */
29     void            *private_data;
30
31 #ifdef CONFIG_EPOLL
32     /* Used by fs/eventpoll.c to link all the hooks to this file */
33     struct list_head    f_ep_links;
34     struct list_head    f_tfile_llink;
35 #endif /* #ifdef CONFIG_EPOLL */
36     struct address_space    *f_mapping;
37 } __attribute__((aligned(4)));    /* lest something weird decides that 2 is OK */

cdev

include/linux/cdev.h

1  struct cdev {
2  13         struct kobject kobj;
3  14         struct module *owner;
4  15         const struct file_operations *ops;
5  16         struct list_head list;
6  17         dev_t dev;
7  18         unsigned int count;
8  19 };
时间: 2024-12-16 15:31:12

linux驱动开发记录的相关文章

Linux GPIO键盘驱动开发记录_OMAPL138

Linux GPIO键盘驱动开发记录_OMAPL138 Linux基本配置完毕了,这几天开始着手Linux驱动的开发,从一个最简单的键盘驱动开始,逐步的了解开发驱动的过程有哪些.看了一下Linux3.3内核文件下的driver目录,点开里面的C文件,感觉底层的Linux驱动机制还是很复杂的,还需要一段漫长时间的学习.现在开发的也不能说是叫做驱动,也只能说是驱动的应用,我们学习驱动也从应用逐步开始,往里面深入吧. 0.开发准备 内核源文件(当时我们编译内核时候的目录,很重要,编译驱动的时候需要依赖

Linux驱动开发之输入子系统

2020-02-15 关键字: Linux 中输入设备大致可分以下几种: 1.按键/键盘(keyboard) 2.鼠标(mouse) 3.触摸屏(touchscreen) 4.游戏杆(joystick) 输入子系统的目的是为了屏蔽众多输入设备在硬件上的差异化,使得在开发输入设备的程序时能更简单统一.输入子系统屏蔽差异的方式就是为各种输入设备与上层应用提供统一的编程接口. Linux 输入子系统是一种编程框架,它可以自上而下分为以下几种层次: 1.应用层 2.input handler层:数据处理

linux驱动开发重点关注内容--摘自《嵌入式Linux驱动模板精讲与项目实践》

本文摘自本人拙著 <嵌入式Linux驱动模板精讲与项目实践> 初步看起来Linux设备驱动开发涉及内容非常多,而须要实现驱动的设备千差万别.事实上做一段时间驱动之后回首看来主要就是下面几点: (1)对驱动进行分类.先归纳为哪个类型的驱动.归类正确再利用内核提供的子系统进行开发,往往会发现事实上非常多通用的事情内核已经帮我们做了,一个优秀的驱动project师应该最大程度上利用内核的资源.内核已经实现的毕竟稳定性强.可移植性高. (2)找到内核的提供的子系统.接下来就是要制作该子系统对该类设备提

【转】linux驱动开发的经典书籍

原文网址:http://www.cnblogs.com/xmphoenix/archive/2012/03/27/2420044.html Linux驱动学习的最大困惑在于书籍的缺乏,市面上最常见的书为<linux_device_driver 3rd Edition>,这是一本很经典的书,无奈Linux的东东还是过于庞大,这本侧重于实战的书籍也只能停留在基本的接口介绍上,更深入的东东只能靠我们自己摸索了.但万事总有一个开头,没有对Linux驱动整体框架的把握是很难做一个优秀的驱动开发者的.除了

Linux 驱动开发笔记(一)

1.查看printk函数日记输出 (1)使用字符终端:通常使用ctrl+alt+f1切换查看: (2)使用cat /proc/kmsg命令:(在Linux系统启动后,/proc/kmsg文件可以查看内核对外所用的符号表,可以用cat命令查看器内容.) (3)使用dmesg命令查看. linux/kernel.h文件定义的printk函数的Log Level: 常数定义语句 意义 #define KERN_EMERG "<0>"/*系统不运行*/ #define KERN_A

Linux驱动开发 -- 打开dev_dbg()

Linux驱动开发 -- 打开dev_dbg() 2012-10-23 19:21:54 分类: LINUX linux设备驱动调试,我们在内核中看到内核使用dev_dbg来控制输出信息,这个函数的实质是调用printk(KERN_DEBUG )来输出打印信息.要打开这个开关需要下面两步. 1.打开调试开关:你调试的文件中必然包含了<linux/device.h>,或者<linux /paltforam_device.h>,后者包含了前者,在包含此头文件之前,使用#define D

s3c6410 Linux 驱动开发环境搭建

s3c6410 Linux 驱动开发环境搭建 -- 既然你是做Linux开发的,你还用虚拟机? 非常多人都在win下做开发,于是SD_writer.exe之类的烧写工具"大行其道",多是用虚拟机Linux. 全然转到Linux下学习開始蛮不爽的,开发板制作商送的教程都是些讲Win-CE的东东,感觉实质性的东西没什么.对于全然用Linux做开发的技术解说非常少,连烧写SD卡都用的win以下的程序.后来找了些资料,整理在这里,希望留给有心人.共同营造一个更好的共同学习的环境. 当别人遇到困

驱动编程思想之初体验 --------------- 嵌入式linux驱动开发之点亮LED

这节我们就开始开始进行实战啦!这里顺便说一下啊,出来做开发的基础很重要啊,基础不好,迟早是要恶补的.个人深刻觉得像这种嵌入式的开发对C语言和微机接口与原理是非常依赖的,必须要有深厚的基础才能hold的住,不然真像一些人说的,学了一年嵌入式感觉还没找到门. 不能再扯了,涉及到linux的驱动开发知识面灰常广,再扯文章就会变得灰常长.首先还是回到led驱动的本身上,自从linux被移植到arm上后,做驱动开发的硬件知识要求有所降低,很多都回归到了软件上,这是系统编程的一大特点,当然 ,也不排除有很多

嵌入式linux驱动开发之点亮led未遂(驱动编程思想之初体验)

有了上两篇文章的基础,我们就可以开始开始进行实战啦!这里顺便说一下啊,出来做开发的基础很重要啊,基础不好,迟早是要恶补的.个人深刻觉得像这种嵌入式的开发对C语言和微机接口与原理是非常依赖的,必须要有深厚的基础才能hold的住,不然真像一些人说的,学了一年嵌入式感觉还没找到门. 另外实践很重要,一年多以前就知道了arm,那时整天用单片机的思维去yy着arm,直到前段时间弄来一块arm板,烧上linux系统后才知道,坑呀!根本不是那回事,所以实践是学习计算机类最重要的基本素质,如果整天看书,那基本上