Introduction to "serial device driver"     （My study note）

膜拜大神的作品.

Standing on the shoulder of the gaints.

——题记

用什么眼光去看待串口设备

当谈到软件对于串口的抽象实现的时候，人们第一反应可能是设备/dev/ttyS0,这个众所周知的串行设备通信的接口文件(至少在PC端是这样的). 由于/dev/ttyS0 是一个char类型的文件，于是一个串口设备通常被认为是一个char driver 驱动着. 很傻很天真，不是这样滴~

事实上“char driver”的抽象并不能完全正确的对设备进行抽象描述，

because there is not specific major number associated to each of them. (这句话不是很懂~)

你可以写新的driver，不要尝试为串口设备添加新的major number (主设备号)

当我们查看串口设备ttyS*   ( ‘ * ‘  通配符) ，我们会发现，这厮的major number都是4 有木有！

问题来了----什么让串口设备驱动和普通的字符设备驱动不同捏？

Since a serial communication channel can be used to plug an alphanumeric terminal, a serial device driver must be integrated in the terminal emulator layer, called the ``tty‘‘ abstraction, from the name of ancient
tele-type devices (still in wide use when Unix was being written)

俯瞰 tty 设备管理

灵活有力的 tty handling 由几个模块组成。毕竟tty设备太多了，而且都很重要。

上图给出了tty core 和 tty driver之间的关系

大多数文件都是放置在 drivers/char
下面，如果不是，这里的目录就放在相关的根目录下咯

下图给出了和串行设备管理的相关文件拓扑图

文件 fs/devices.c 导出接口用于大多数系统资源的注册，每个device driver 由 major number 唯一确定。

这就是 为何当我们需要支持新的tty driver的时候，  tty_register_driver() 函数需要获得major number number. 这个函数在tty_io.c 里面定义，并且该文件还定义了和tty 设备相关的文件操作.

设备相关driver 来实现对于设备操作的支持，这些操作就涉及数据的输入输出，数据流的控制以及和更上一层的交互. 这些文件操作和中断一起，实际操控着数据的IO.

数据在用户空间和串口设备驱动之间隔着一个tty 层(tty line discipline),用于实现数据的转换. 这点在LDD3里就有讲~

并不是所有的tty 管理操作都在 tty_io.c 里面定义，大多数策略(policy) 是在   line discipline定义的，这是一个软件模块，控制物理的tty I/O 如何使用.

默认的  line discipline for 叫 N_TTY.  如果 n_tty 处于active 状态,输入数据通过通常的/dev/ 接口和标准的terminal I/O 函数来达到 用户空间.

图中的红线显示出对数据流动的逻辑控制，从硬件通道上至用户空间可以涉及的设备相关文件(/dev/目录下的文件)

而链接这一切的是 stryct tty ，在这个结构体里面包含了一个指针，这个指针指向所有相关的模块:

• file_operations(用于和用户空间通信交互)
• struct tty_driver则实际掌控着控制硬件操作的部分，
•  struct tty_ldisc 则列出所有当前 line discipline 的入口指针

为啥这么麻烦？

这类组织管理方式看似麻烦复杂，然而这种额外付出的复杂性可以获得更加好的灵活性，使得模块更加强大。

便于对于不同的tty设备更改 line discipline.

普通的设备驱动就是在硬件和用户空间之间的通信桥梁。和普通的设备驱动不同， a serial driver 和用户空间没啥关系。a serial driver  接受到来自硬件的设备都不是直接传给用户空间的，它传给  line discipline, 并且 也几乎不直接接受用户空间数据，它的数据来源于 一个 line discipline method.

一个单独的serial driver不是用户空间和硬件之间的数据转换者.

The task is left to the line discipline, together with all the hairy termios handling. This makes it possible for serial data to be steered to a different user-space access facility than
its associated ttyS device special file.

一些相关的数据结构

这里有三种和tty 管理相关的主要的数据结构

• struct tty_struct 
• struct tty_driver: this is the low level hardware handling. At open time, the function get_tty_driver retrieves the driver for the current tty an places it into the driver field of tty_struct,
  where it is further accessed.

• struct tty_driver {
  
  	    /* the driver states which range of devices it supports */
  	    short major;         /* major device number */
  	    short minor_start;   /* start of minor device number*/
  	    short   num;         /* number of devices */
  
  	    /* and has its own operations */
  	    int  (*open)();
  	    void (*close)();
  	    int  (*write)();
  	    int  (*ioctl)();  /* device-specific control */
  
  	    /* return information on buffer state */
  	    int  (*write_room)();      /* how much can be written */
  	    int  (*chars_in_buffer)(); /* how much is there to read */
  
  	    /* flow control, input and output */
  	    void (*throttle)();
  	    void (*unthrottle)();
  	    void (*stop)();
  	    void (*start)();
  
  	    /* and callbacks for /proc/tty/driver/ */
  	    int (*read_proc)();
  	    int (*write_proc)();
  	};

• struct tty_ldisc: the structure is referenced by the ldisc field of tty_struct. At open time the field is initialized to reference n_tty, and user programs can change the current
  line discipline via ioctl, as explained in a while.

• 	struct tty_ldisc {
  
  	    /* routines called from above */
  	    int     (*open)();
  	    void    (*close)();
  	    ssize_t (*read)();
  	    ssize_t (*write)();
  	    int     (*ioctl)();
  
  	    /* routines called from below */
  	    void    (*receive_buf)();
  	    int     (*receive_room)();
  	    void    (*write_wakeup)();
  	};
  	

这些数据结构在三个不同的文件里面定义，  tty_struct 这个复杂的大家伙在 include/linux/tty.h 里面，相比另外两个结构体，其实这个东东用的少~.

include/linux/tty_driver.h and include/linux/tty_ldisc.h 定义了另外两个结构体.   不像tty_struct,   tty_driver 和 tty_ldisc 都是module 作者常用的东东~

对于数据流的读写

向串口写数据的时候，是很直接的，中间没有buffer。但是从串口读数据就麻烦点了，而且这个时候中间是有buffer的。  数据被储存在buffer里面，知道用户空间的程序需求他们的时候，这个buffer里的数据就会传递到用户空间.

不管什么时候，当用户程序要从串口读数据的时候，这个时候buffer是空的，那么此时用户程序陷入休眠，直到buffer被填充。

注意到，write buffer 实际上也是存在的，只是实现的很直接，  因为write操作的每一步都由上一级驱动（注意图中的箭头是左边write操作是单向的，而右边read操作是双向的）。

read buffer 是放在struct tty 里面的，由于是动态分配的，所以不存在内存的浪费.

实际上，tty相关的buffer被分做两级管理: kernel developers chose to provide both a ``conventional‘‘ buffer, where data is waiting to be eaten by the line discipline (i.e., in the default case, being
transferred to user space), and a ``flip‘‘ buffer, used by hardware routines to store incoming data as quickly as possible, without the need to synchronize for concurrent access: flip buffers are exclusive ownership of the hardware device, which eventually
calls tty_flip_buffer_push to deliver data to the tty buffer, where the line discipline pulls it from.

It‘s interesting to note that the flip buffer is laid out as two physical buffers that are alternatively written to. This allows more reliable operation, as the interrupt handler will always have
a whole buffer available for writing. The function flush_to_ldisc, called by the low-level driver and part of the tty layer (i.e., tty_io.c), arranges for the flip buffer to be flipped, before the interrupt handler returns. This layout, by
the way, is why the flip buffer is called so.

register_serial  扮演的角色

如果你注意到 drivers/char/serial.c  导出了一个叫 register_serial 的函数，你会琢磨这家伙在 tty 构架中扮演什么角色呢？

事实上，这个功能仅仅是为了更便利容易的在运行时去添加标准的串口设备tty 驱动，