LINUX下的tty，console与串口分析

一、LINUX下TTY、CONSOLE、串口之间是怎样的层次关系？具体的函数接口是怎样的？串口是如何被调用的？ 

二、printk函数是把信息发送到控制台上吧？如何让PRINTK把信息经过串口送出？或者说系统在什么地方来决定是将信息送到显示器仍是串口？ 


三、start_kernel中一开始就用到了printk函数（好象是printk(linux_banner什么的），在 这个时候整个内核还没跑起来呢那这时候的printk是如何被调用的？在咱们的系统中，系统启动是用的现代公司的BOOTLOADER程序，后来好象跳到了LINUX下的head-armv.s， 而后跳到start_kernel，在bootloader 里串口已是可用的了，那么在进入内核后是否是要从新设置？ 


以上问题可能问的比较乱，由于我本身脑子里也比较乱，主要仍是对tty,console,serial之间的关系，特别是串口是如何被调用的没搞清这方面的资料又比较少（就情景分析中讲了一点），但愿高手能指点一二，很是谢！

我最近也在搞这方面的东西，也是写一个串口设备的驱动 
搞了将近一个月了，其中上网找资料，看源代码，什么都作了 
但仍是一蹋糊涂的，有些问题仍是不明白，但愿一块儿讨论讨论 

在/proc/device（没记错应该是这个文件） 
里面有一个叫serial的驱动，其主设备号是4，次设备号是64-12X（没记错应该是这个范围） 
你们都知道，串口的次设备号是从64开始的，串口1 /dev/ttyS0就对应次设备号64，串口2就对应65 
问题是如今我机上只有两个串口，它注册这么屡次设备号来干什么？ 

对于一个接在串口1的设备，在我注册驱动的时候 
我是须要本身找一个主设备号呢？ 
仍是就用主设备号4，次设备号从上面12X的后面选？ 
仍是就用主设备号4，次设备号64？ 

在linux的内核中有一个tty层，我看好像有些串口驱动是从这里开始的 
例如调用tty_register_driver()来注册驱动 
就像在pci子系统里调用pci_register_driver()那样的 
那么，用这种机制来注册的驱动， 
它是直接对串口的端口操做呢（例如用inb(),outb()....之类的） 
仍是某些更底层的驱动接口呢？ 

这些问题缠了我好久都没解决，搞得最后不得不放弃 
如今转向用户空间的应用程序，看能不能有些更高效的方法来实现 
（在用户空间只能用open("/dev/ttyS0", O_RDWR)来实现了）

另外还有，系统里已经为咱们实现了串口的驱动 
因此咱们在用户空间的程序里直接open("/dev/ttyS0")就可用了 
可是如今要写的是接在串口上的设备的驱动 
在内核模块中可不能够包含某个头文件，而后就能够直接用串口驱动中的接口呢？

看到大家的问题后，感受颇有典型性，所以花了点工夫看了一下，作了一些心得贴在这里，欢迎讨论并指正： 
一、LINUX下TTY、CONSOLE、串口之间是怎样的层次关系？具体的函数接口是怎样的？串口是如何被调用的？ 
tty和console这些概念主要是一些虚设备的概念，而串口更多的是指一个真正的设备驱动Tty实际是一类终端I/O设备的抽象，它实际上更多的是一个管理的概念，它和tty_ldisc（行规程）和tty_driver（真实设备驱动）组合在一块儿，目的是向上层的VFS提供一个统一的接口经过file_operations结构中的tty_ioctl能够对其进行配置 。查tty_driver，你将获得n个结果，实际都是相关芯片的驱动所以，能够获得的结论是（实际状况比这复杂得多）：每一个描述tty设备的tty_struct在初始化时必然挂如了某个具体芯片的字符设备驱动（不必定是字符设备驱动），能够是不少，包括显卡或串口chip不知道你的ARM Soc是那一款，不过看状况大家应该用的是常见的chip，这些驱动实际上都有而console是一个缓冲的概念，它的目的有一点相似于tty实际上console不只和tty连在一块儿，还和framebuffer连在一块儿，具体的缘由看下面的键盘的中断处理过程Tty的一个子集须要使用console(典型的如主设备号4，次设备号1―64)，可是要注意的是没有console的tty是存在的
而串口则指的是tty_driver举个典型的例子： 
分析一下键盘的中断处理过程： 
keyboard_interrupt―>handle_kbd_event―>handle_keyboard_event―>handle_scancode 
void handle_scancode(unsigned char scancode, int down) 
{ 
…….. 
tty = ttytab? ttytab[fg_console]: NULL; 
if (tty && (!tty->driver_data)) { 
…………… 
tty = NULL; 
} 
…………. 
schedule_console_callback(); 
} 
这段代码中的两个地方很值得注意，也就是除了得到tty外（经过全局量tty记录），还进行了console 回显schedule_console_callbackTty和console的关系在此已经很明了！！！ 

二、printk函数是把信息发送到控制台上吧？如何让PRINTK把信息经过串口送出？或者说系统在什么地方来决定是将信息送到显示器仍是串口？ 
具体看一下printk函数的实现就知道了，printk不必定是将信息往控制台上输出，设置kernel的启动参数可能能够打到将信息送到显示器的效果。函数前有一段英文，颇有意思： 
/*This is printk. It can be called from any context. We want it to work. 
* 
* We try to grab the console_sem. If we succeed, it's easy - we log the output and 
* call the console drivers. If we fail to get the semaphore we place the output 
* into the log buffer and return. The current holder of the console_sem will 
* notice the new output in release_console_sem() and will send it to the 
* consoles before releasing the semaphore. 
* 
* One effect of this deferred printing is that code which calls printk() and 
* then changes console_loglevel may break. This is because console_loglevel 
* is inspected when the actual printing occurs. 
*/ 
这段英文的要点：要想对console进行操做，必须先要得到console_sem信号量若是得到console_sem信号量，则能够“log the output and call the console drivers”，反之，则“place the output into the log buffer and return”，实际上，在代码： 
asmlinkage int printk(const char *fmt, ...) 
{ 
va_list args; 
unsigned long flags; 
int printed_len; 
char *p; 
static char printk_buf[1024]; 
static int log_level_unknown = 1; 
if (oops_in_progress) { /*若是为1状况下，必然是系统发生crush*/ 
/* If a crash is occurring, make sure we can't deadlock */ 
spin_lock_init(&logbuf_lock); 
/* And make sure that we print immediately */ 
init_MUTEX(&console_sem); 
} 
/* This stops the holder of console_sem just where we want him */ 
spin_lock_irqsave(&logbuf_lock, flags); 
/* Emit the output into the temporary buffer */ 
va_start(args, fmt); 
printed_len = vsnprintf(printk_buf, sizeof(printk_buf), fmt, args);/*对传入的buffer进行处理，注意还不是 
真正的对终端写，只是对传入的string进行格式解析*/ 
va_end(args); 
/*Copy the output into log_buf. If the caller didn't provide appropriate log level tags, we insert them here*/ 
/*注释很清楚*/ 
for (p = printk_buf; *p; p++) { 
if (log_level_unknown) { 
if (p[0] != '<' || p[1] < '0' || p[1] > '7' || p[2] != '>') { 
emit_log_char('<'); 
emit_log_char(default_message_loglevel + '0'); 
emit_log_char('>'); 
} 
log_level_unknown = 0; 
} 
emit_log_char(*p); 
if (*p == '\n') 
log_level_unknown = 1; 
} 
if (!arch_consoles_callable()) { 
/*On some architectures, the consoles are not usable on secondary CPUs early in the boot process.*/ 
spin_unlock_irqrestore(&logbuf_lock, flags); 
goto out; 
} 
if (!down_trylock(&console_sem)) { 
/*We own the drivers. We can drop the spinlock and let release_console_sem() print the text*/ 
spin_unlock_irqrestore(&logbuf_lock, flags); 
console_may_schedule = 0; 
release_console_sem(); 
} else { 
/*Someone else owns the drivers. We drop the spinlock, which allows the semaphore holder to 
proceed and to call the console drivers with the output which we just produced.*/ 
spin_unlock_irqrestore(&logbuf_lock, flags); 
} 
out: 
return printed_len; 
} 
实际上printk是将format后的string放到了一个buffer中，在适当的时候再加以show,这也回答了在start_kernel中一开始就用到了printk函数的缘由 

三、start_kernel中一开始就用到了printk函数（好象是printk(linux_banner什么的)，在这个时候整个内核还没跑起来呢 。那这时候的printk是如何被调用的？在咱们的系统中，系统启动是用的现代公司的BOOTLOADER程序，后来好象跳到了LINUX下的head-armv.s， 而后跳到start_kernel，在bootloader 里串口已是可用的了，那么在进入内核后是否是要从新设置？ 
Bootloader通常会作一些基本的初始化，将kernel拷贝物理空间，而后再跳到kernel去执行。能够确定的是kernel确定要对串口进行从新设置，缘由是Bootloader有不少种，有些不必定对串口进行设置，内核不能依赖于bootloader而存在。

 

多谢楼上大侠，分析的很精辟 。我正在看printk函数。

咱们用的CPU是hynix的hms7202。在评估板上是用串口0做 
控制台，全部启动过程当中的信息都是经过该串口送出的。 
在bootloader中定义了函数ser_printf经过串口进行交互。

但我仍是没想明白在跳转到linux内核而console和串口还没有 
初始化时printk是如何可以工做的？我看了start_kernel 
的过程（并经过超级终端做了一些跟踪），console的初始化 
是在console_init函数里，而串口的初始化其实是在1号 
进程里（init->do_basic_setup->do_initcalls->rs_init)， 
那么在串口没有初始化之前prink是如何工做的？特别的，在 
start_kernel一开始就有printk(linux_banner)，而这时候 
串口和console都还没有初始化呢。

 

1.在start_kernel一开始就有printk(linux_banner)，而这时候串口和console都还没有初始化? 
仔细分析printk能够对该问题进行解答代码中的： 
/* Emit the output into the temporary buffer */ 
va_start(args, fmt); 
printed_len = vsnprintf(printk_buf, sizeof(printk_buf), fmt, args); 
va_end(args); 
将输入放到了printk_buf中，接下来的 
for (p = printk_buf; *p; p++) { 
if (log_level_unknown) { 
if (p[0] != '<' || p[1] < '0' || p[1] > '7' || p[2] != '>') { 
emit_log_char('<'); 
emit_log_char(default_message_loglevel + '0'); 
emit_log_char('>'); 
} 
log_level_unknown = 0; 
} 
emit_log_char(*p); 
if (*p == '\n') 
log_level_unknown = 1; 
} 
则将printk_buf中的内容进行解析并放到全局的log_buf（在emit_log_char函数）中if (!down_trylock(&console_sem)) { 
/* 
* We own the drivers. We can drop the spinlock and let 
* release_console_sem() print the text 
*/ 
spin_unlock_irqrestore(&logbuf_lock, flags); 
console_may_schedule = 0; 
release_console_sem(); 
} else { 
/* 
* Someone else owns the drivers. We drop the spinlock, which 
* allows the semaphore holder to proceed and to call the 
* console drivers with the output which we just produced. 
*/ 
spin_unlock_irqrestore(&logbuf_lock, flags); 
} 
则是根据down_trylock(&console_sem)的结果调用release_console_sem()，在release_console_sem()中才真正的对全局的log_buf中的内容相应的console设备驱动进行处理 。至此，能够获得以下的一些结论： 
（1）printk的主操做实际上仍是针对一个buffer(log_buf),该buffer中的内容是否显示（或者说向终端输出），则要看是否能够得到console_sem（2）printk所在的文件为printk.c，是和体系结构无关的，所以对任何平台都同样 。 能够推测的结论是：
（1）kernel在初始化时将console_sem标为了locked，所以在start_kernel一开始的printk(linux_banner)中实际只将输入写入了缓冲，等在串口和console初始化后，对printk的调用才一次将缓冲中的内容向串口和console输出 。 （2）在串口和console的初始化过程当中，必然有对console_sem的up操做 。 
（3）所以，在embedded的调试中，若是在console的初始化以前系统出了问题，不会有任何的输出 。 惟一可使用的只能是led或jtag了 。（4）所以，你的问题能够看出解答 。2.console的初始化. 
不知道你用的是那一个内核版本，在我看的2.4.18和2.4.19中，都是在start_kernel中就对console进行的初始化 。从前面的分析来看，console的初始化不该该太晚，不然log_buf有可能溢出 。

多谢楼上，分析的很精彩！ 

咱们用的内核版本是2.4.18，console的初始化确实是在 
start_kernel->console->init 。关于tty和串口，我这里还想再问一下tty设备的操做的总入口 
是 

static struct file_operations tty_fops = { 
llseek: no_llseek, 
read: tty_read, 
write: tty_write, 
poll: tty_poll, 
ioctl: tty_ioctl, 
open: tty_open, 
release: tty_release, 
fasync: tty_fasync, 
}; 

而对串口的操做定义在： 

static struct tty_driver serial_driver 这个结构中
serial.c中的多数函数都是填充serial_driver中的函数指针
那么在对串口操做时，应该是先调用tty_fops中的操做（好比 
tty_open等），而后再分流到具体的串口操做（rs_open等）吧？ 
但tty_driver（对串口就是serial_driver)中有不少函数指针 
并不跟file_operations中的函数指针对应，不知道这些对应 
不上的操做是如何被执行的？好比put_char,flush_char,read_proc, 
write_proc,start,stop等 。

如下是我对这个问题的一些理解： 
这实际上仍是回到原先的老问题，即tty和tty_driver之间的关系 。从实现上看，tty_driver其实是tty机制的实现组件之一，借用面向对象设计中的经常使用例子，这时的tty_driver就象是tty这部汽车的轮胎，tty这部汽车要正常运行，还要tty_ldisc（行规程），termios，甚至struct tq_struct tq_hangup（看tty_struct）等基础设施。它们之间的关系并不是继承。至于tty_driver中的函数指针，再打个C++中的比喻，它们实际上很象虚函数，也就是说，能够定义它们，但并不必定实现它们、实际上还不用说tty_driver，只要查一下serial_driver都会发现n多个具体的实现，但对各个具体的设备，其tty_driver中的函数不必定所有实现、因此put_char,flush_char,read_proc, write_proc,start,stop这些函数的状况是有可能实现，也有可能不实现 即便被实现，也不必定为上层(VFS层)所用.