首頁(yè) > 產(chǎn)業(yè) > 產(chǎn)品
找一篇刀劍亂舞的同人，審神者非常厲害，初始刀是清光，然后由于時(shí)之政府作死，在她出去的時(shí)候把她本丸里
是指xx刀x女審神者的這種嗎。）我表達(dá)可能不太清楚,不懂的話追問(wèn)吧女審神者就是指玩家?如果是這樣的話只是別人喜歡xx刀x女審神者,你不喜歡的話就別看嘛你是女孩子的話你也是女審神者啊不過(guò)你人設(shè)是男孩子的話就是男審神者了（!審神者指的就是刀的主人.玩刀劍亂舞的每一個(gè)人都是審神者我認(rèn)為女審神者就是指女性審神者刀劍是女性向游戲并不是乙女順便沒(méi)有弄懂拆你cp是怎么拆
電腦開(kāi)機(jī)時(shí)恢復(fù)到初始狀態(tài)是怎么回事
這種現(xiàn)象通常有以下幾個(gè)原因：1系統(tǒng)加了還原。2bios設(shè)置里邊出現(xiàn)異常3C盤(pán)有錯(cuò)誤解決辦法：1卸載還原之類(lèi)的東西，有些軟件帶了部分還原功能，如果不知道什么軟件的話，重新做系統(tǒng)，如果OK，那就是軟件的問(wèn)題，如果NG，那就不是軟件的原因，考慮以下兩種情況。2恢復(fù)bios設(shè)置，拔出bois電池，反裝上去至少5秒，再重新裝回來(lái)，如果問(wèn)題解決，那就OK，沒(méi)有的話，就考慮下面一種情況了。3C盤(pán)有錯(cuò)誤，它會(huì)保存不住數(shù)據(jù)，用軟件檢查一下磁盤(pán)，看看有沒(méi)有壞道就行了。
linux 啟動(dòng)時(shí)何時(shí)初始化console，串口等
1、LINUX下TTY、CONSOLE、串口之間是怎樣的層次關(guān)系？具體的函數(shù)接口是怎樣的？串口是如何被調(diào)用的？?
2、printk函數(shù)是把信息發(fā)送到控制臺(tái)上吧？如何讓PRINTK把信息通過(guò)串口送出？或者說(shuō)系統(tǒng)在什么地方來(lái)決定是將信息送到顯示器還是串口？?
3、start_kernel中一開(kāi)始就用到了printk函數(shù)（好象是printk(linux_banner什么的），在 這個(gè)時(shí)候整個(gè)內(nèi)核還沒(méi)跑起來(lái)呢那這時(shí)候的printk是如何被調(diào)用的？在我們的系統(tǒng)中，系統(tǒng)啟動(dòng)是用的現(xiàn)代公司的BOOTLOADER程序，后來(lái)好象跳到了LINUX下的head-armv.s， 然后跳到start_kernel，在bootloader 里串口已經(jīng)是可用的了，那么在進(jìn)入內(nèi)核后是不是要重新設(shè)置？?
以上問(wèn)題可能問(wèn)的比較亂，因?yàn)槲易约耗X子里也比較亂，主要還是對(duì)tty,console,serial之間的關(guān)系，特別是串口是如何被調(diào)用的沒(méi)搞清這方面的資料又比較少（就情景分析中講了一點(diǎn)），希望高手能指點(diǎn)一二，非常謝！
我最近也在搞這方面的東西，也是寫(xiě)一個(gè)串口設(shè)備的驅(qū)動(dòng)?
搞了將近一個(gè)月了，其中上網(wǎng)找資料，看源代碼，什么都做了?
但還是一蹋糊涂的，有些問(wèn)題還是不明白，希望一起討論討論?
在/proc/device（沒(méi)記錯(cuò)應(yīng)該是這個(gè)文件）?
里面有一個(gè)叫serial的驅(qū)動(dòng)，其主設(shè)備號(hào)是4，次設(shè)備號(hào)是64-12X（沒(méi)記錯(cuò)應(yīng)該是這個(gè)范圍）?
大家都知道，串口的次設(shè)備號(hào)是從64開(kāi)始的，串口1 /dev/ttyS0就對(duì)應(yīng)次設(shè)備號(hào)64，串口2就對(duì)應(yīng)65?
問(wèn)題是現(xiàn)在我機(jī)上只有兩個(gè)串口，它注冊(cè)這么多次設(shè)備號(hào)來(lái)干什么？?
對(duì)于一個(gè)接在串口1的設(shè)備，在我注冊(cè)驅(qū)動(dòng)的時(shí)候?
我是需要自己找一個(gè)主設(shè)備號(hào)呢？?
還是就用主設(shè)備號(hào)4，次設(shè)備號(hào)從上面12X的后面選？?
還是就用主設(shè)備號(hào)4，次設(shè)備號(hào)64？?
在linux的內(nèi)核中有一個(gè)tty層，我看好像有些串口驅(qū)動(dòng)是從這里開(kāi)始的?
例如調(diào)用tty_register_driver()來(lái)注冊(cè)驅(qū)動(dòng)?
就像在pci子系統(tǒng)里調(diào)用pci_register_driver()那樣的?
那么，用這種機(jī)制來(lái)注冊(cè)的驅(qū)動(dòng)，?
它是直接對(duì)串口的端口操作呢（例如用inb(),outb()....之類(lèi)的）?
還是某些更底層的驅(qū)動(dòng)接口呢？?
這些問(wèn)題纏了我很久都沒(méi)解決，搞得最后不得不放棄?
現(xiàn)在轉(zhuǎn)向用戶空間的應(yīng)用程序，看能不能有些更高效的方法來(lái)實(shí)現(xiàn)?
（在用戶空間只能用open(/dev/ttyS0, O_RDWR)來(lái)實(shí)現(xiàn)了）
另外還有，系統(tǒng)里已經(jīng)為我們實(shí)現(xiàn)了串口的驅(qū)動(dòng)?
所以我們?cè)谟脩艨臻g的程序里直接open(/dev/ttyS0)就可用了?
但是現(xiàn)在要寫(xiě)的是接在串口上的設(shè)備的驅(qū)動(dòng)?
在內(nèi)核模塊中可不可以包含某個(gè)頭文件，然后就可以直接用串口驅(qū)動(dòng)中的接口呢？
看到你們的問(wèn)題后，感覺(jué)很有典型性，因此花了點(diǎn)工夫看了一下，做了一些心得貼在這里，歡迎討論并指正：?
1、LINUX下TTY、CONSOLE、串口之間是怎樣的層次關(guān)系？具體的函數(shù)接口是怎樣的？串口是如何被調(diào)用的？?
tty和console這些概念主要是一些虛設(shè)備的概念，而串口更多的是指一個(gè)真正的設(shè)備驅(qū)動(dòng)Tty實(shí)際是一類(lèi)終端I/O設(shè)備的抽象，它實(shí)際上更多的是一個(gè)管理的概念，它和tty_ldisc（行規(guī)程）和tty_driver（真實(shí)設(shè)備驅(qū)動(dòng)）組合在一起，目的是向上層的VFS提供一個(gè)統(tǒng)一的接口通過(guò)file_operations結(jié)構(gòu)中的tty_ioctl可以對(duì)其進(jìn)行配置。查tty_driver，你將得到n個(gè)結(jié)果，實(shí)際都是相關(guān)芯片的驅(qū)動(dòng)因此，可以得到的結(jié)論是（實(shí)際情況比這復(fù)雜得多）：每個(gè)描述tty設(shè)備的tty_struct在初始化時(shí)必然掛如了某個(gè)具體芯片的字符設(shè)備驅(qū)動(dòng)（不一定是字符設(shè)備驅(qū)動(dòng)），可以是很多，包括顯卡或串口chip不知道你的ARM Soc是那一款，不過(guò)看情況你們應(yīng)該用的是常見(jiàn)的chip，這些驅(qū)動(dòng)實(shí)際上都有而console是一個(gè)緩沖的概念，它的目的有一點(diǎn)類(lèi)似于tty實(shí)際上console不僅和tty連在一起，還和framebuffer連在一起，具體的原因看下面的鍵盤(pán)的中斷處理過(guò)程Tty的一個(gè)子集需要使用console(典型的如主設(shè)備號(hào)4，次設(shè)備號(hào)1―64)，但是要注意的是沒(méi)有console的tty是存在的
而串口則指的是tty_driver舉個(gè)典型的例子：?
分析一下鍵盤(pán)的中斷處理過(guò)程：?
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();?
}?
這段代碼中的兩個(gè)地方很值得注意，也就是除了獲得tty外（通過(guò)全局量tty記錄），還進(jìn)行了console 回顯schedule_console_callbackTty和console的關(guān)系在此已經(jīng)很明了?。。?
2、printk函數(shù)是把信息發(fā)送到控制臺(tái)上吧？如何讓PRINTK把信息通過(guò)串口送出？或者說(shuō)系統(tǒng)在什么地方來(lái)決定是將信息送到顯示器還是串口？?
具體看一下printk函數(shù)的實(shí)現(xiàn)就知道了，printk不一定是將信息往控制臺(tái)上輸出，設(shè)置kernel的啟動(dòng)參數(shù)可能可以打到將信息送到顯示器的效果。函數(shù)前有一段英文，很有意思：?
/*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.?
*/?
這段英文的要點(diǎn)：要想對(duì)console進(jìn)行操作，必須先要獲得console_sem信號(hào)量如果獲得console_sem信號(hào)量，則可以“l(fā)og the output and call the console drivers”，反之，則“place the output into the log buffer and return”，實(shí)際上，在代碼：?
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情況下，必然是系統(tǒng)發(fā)生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);/*對(duì)傳入的buffer進(jìn)行處理，注意還不是?
真正的對(duì)終端寫(xiě)，只是對(duì)傳入的string進(jìn)行格式解析*/?
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;?
}?
實(shí)際上printk是將format后的string放到了一個(gè)buffer中，在適當(dāng)?shù)臅r(shí)候再加以show,這也回答了在start_kernel中一開(kāi)始就用到了printk函數(shù)的原因?
3、start_kernel中一開(kāi)始就用到了printk函數(shù)（好象是printk(linux_banner什么的)，在這個(gè)時(shí)候整個(gè)內(nèi)核還沒(méi)跑起來(lái)呢。那這時(shí)候的printk是如何被調(diào)用的？在我們的系統(tǒng)中，系統(tǒng)啟動(dòng)是用的現(xiàn)代公司的BOOTLOADER程序，后來(lái)好象跳到了LINUX下的head-armv.s， 然后跳到start_kernel，在bootloader 里串口已經(jīng)是可用的了，那么在進(jìn)入內(nèi)核后是不是要重新設(shè)置？?
Bootloader一般會(huì)做一些基本的初始化，將kernel拷貝物理空間，然后再跳到kernel去執(zhí)行。可以肯定的是kernel肯定要對(duì)串口進(jìn)行重新設(shè)置，原因是Bootloader有很多種，有些不一定對(duì)串口進(jìn)行設(shè)置，內(nèi)核不能依賴于bootloader而存在。
多謝樓上大俠，分析的很精辟。我正在看printk函數(shù)。
我們用的CPU是hynix的hms7202。在評(píng)估板上是用串口0作?
控制臺(tái)，所有啟動(dòng)過(guò)程中的信息都是通過(guò)該串口送出的。?
在bootloader中定義了函數(shù)ser_printf通過(guò)串口進(jìn)行交互。
但我還是沒(méi)想明白在跳轉(zhuǎn)到linux內(nèi)核而console和串口尚未?
初始化時(shí)printk是如何能夠工作的？我看了start_kernel?
的過(guò)程（并通過(guò)超級(jí)終端作了一些跟蹤），console的初始化?
是在console_init函數(shù)里，而串口的初始化實(shí)際上是在1號(hào)?
進(jìn)程里（init->do_basic_setup->do_initcalls->rs_init)，?
那么在串口沒(méi)有初始化以前prink是如何工作的？特別的，在?
start_kernel一開(kāi)始就有printk(linux_banner)，而這時(shí)候?
串口和console都尚未初始化呢。
在start_kernel一開(kāi)始就有printk(linux_banner)，而這時(shí)候串口和console都尚未初始化??
仔細(xì)分析printk可以對(duì)該問(wèn)題進(jìn)行解答代碼中的：?
/* 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中，接下來(lái)的?
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中的內(nèi)容進(jìn)行解析并放到全局的log_buf（在emit_log_char函數(shù)）中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);?
}?
則是根據(jù)down_trylock(&console_sem)的結(jié)果調(diào)用release_console_sem()，在release_console_sem()中才真正的對(duì)全局的log_buf中的內(nèi)容相應(yīng)的console設(shè)備驅(qū)動(dòng)進(jìn)行處理。至此，可以得到如下的一些結(jié)論：?
（1）printk的主操作實(shí)際上還是針對(duì)一個(gè)buffer(log_buf),該buffer中的內(nèi)容是否顯示（或者說(shuō)向終端輸出），則要看是否可以獲得console_sem（2）printk所在的文件為printk.c，是和體系結(jié)構(gòu)無(wú)關(guān)的，因此對(duì)任何平臺(tái)都一樣。 可以推測(cè)的結(jié)論是：?
（1）kernel在初始化時(shí)將console_sem標(biāo)為了locked，因此在start_kernel一開(kāi)始的printk(linux_banner)中實(shí)際只將輸入寫(xiě)入了緩沖，等在串口和console初始化后，對(duì)printk的調(diào)用才一次將緩沖中的內(nèi)容向串口和console輸出。 （2）在串口和console的初始化過(guò)程中，必然有對(duì)console_sem的up操作。?
（3）因此，在embedded的調(diào)試中，如果在console的初始化之前系統(tǒng)出了問(wèn)題，不會(huì)有任何的輸出。 唯一可以使用的只能是led或jtag了。（4）因此，你的問(wèn)題可以看出解答。2.console的初始化.?
不知道你用的是那一個(gè)內(nèi)核版本，在我看的2.4.18和2.4.19中，都是在start_kernel中就對(duì)console進(jìn)行的初始化。從前面的分析來(lái)看，console的初始化不應(yīng)該太晚，否則log_buf有可能溢出。
多謝樓上，分析的很精彩！?
我們用的內(nèi)核版本是2.4.18，console的初始化確實(shí)是在?
start_kernel->console->init。關(guān)于tty和串口，我這里還想再問(wèn)一下tty設(shè)備的操作的總?cè)肟?
是?
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,?
};?
而對(duì)串口的操作定義在：?
static struct tty_driver serial_driver 這個(gè)結(jié)構(gòu)中
serial.c中的多數(shù)函數(shù)都是填充serial_driver中的函數(shù)指針
那么在對(duì)串口操作時(shí)，應(yīng)該是先調(diào)用tty_fops中的操作（比如?
tty_open等），然后再分流到具體的串口操作（rs_open等）吧？?
但tty_driver（對(duì)串口就是serial_driver)中有很多函數(shù)指針?
并不跟file_operations中的函數(shù)指針對(duì)應(yīng)，不知道這些對(duì)應(yīng)?
不上的操作是如何被執(zhí)行的？比如put_char,flush_char,read_proc,?
write_proc,start,stop等。
以下是我對(duì)這個(gè)問(wèn)題的一些理解：?
這實(shí)際上還是回到原先的老問(wèn)題，即tty和tty_driver之間的關(guān)系。從實(shí)現(xiàn)上看，tty_driver實(shí)際上是tty機(jī)制的實(shí)現(xiàn)組件之一，借用面向?qū)ο笤O(shè)計(jì)中的常用例子，這時(shí)的tty_driver就象是tty這部汽車(chē)的輪胎，tty這部汽車(chē)要正常運(yùn)行，還要tty_ldisc（行規(guī)程），termios，甚至struct tq_struct tq_hangup（看tty_struct）等基礎(chǔ)設(shè)施。它們之間的關(guān)系并非繼承。至于tty_driver中的函數(shù)指針，再打個(gè)C++中的比喻，它們實(shí)際上很象虛函數(shù)，也就是說(shuō)，可以定義它們，但并不一定實(shí)現(xiàn)它們、實(shí)際上還不用說(shuō)tty_driver，只要查一下serial_driver都會(huì)發(fā)現(xiàn)n多個(gè)具體的實(shí)現(xiàn)，但對(duì)各個(gè)具體的設(shè)備，其tty_driver中的函數(shù)不一定全部實(shí)現(xiàn)、所以put_char,flush_char,read_proc, write_proc,start,stop這些函數(shù)的情況是有可能實(shí)現(xiàn)，也有可能不實(shí)現(xiàn) 即使被實(shí)現(xiàn)，也不一定為上層(VFS層)所用.
強(qiáng)推
