我們現在的系統有乙個原則：就是基本上所有的配置都是預設的，所以在梳理包處理流程遇到各種暫存器的時候先假設暫存器沒有被配置過（預設狀態）
包輸入流程：
硬體流程
mac—— dpi —— pip/ipd —— sso —— core
資料狀態
包資料 —— dpi_inst_hdr+包資料 —— pkt_inst_hdr+包資料 —— pkt_inst_hdr和包資料的組合 —— wqe節點
dpi是直接訪問mac的介面；dpi中有32個ring，這32個ring各自有各自的pkind區分
包資料進入，存在mac上，然後ring從mac上抓取包資料，並建立一條指令，dpi_inst_hdr，然後用dpi_inst_hdr在一些配置的作用下轉換成一條pkt_inst_hdr指令，將這個pkt_inst_hdr指令和包資料組合起來傳入到pip/ipd上
，然後pip/ipd根據配置和
pkt_inst_hdr指令中包含的資訊/包資料，建立wqe節點，然後將wqe節點傳入sso，sso排程wqe給core處理
wqe中排程欄位的**
tag_type：由~/v5/cdk3/linux/kernel_2.6/linux/arch/mips/include/asm/octeon/cvmx-config.h 中的配置生效
tag_value：由include/mpp_init.c 中 mc_pip_port_intialize函式 配置決定(使用五元組還是只用vlan id)
pkind：應該先於qos得到，在初始化xaui口的時候全部被設定成5，但是列印結果是每乙個xuia口都有不同的pkind，顯然在設定xuia和獲取qos之間應該有對pkind的修改；
xaui口的pkind是gmx(0..4)_prt(0..3)_cfg[pknd]暫存器決定的，32個ring中的pind是由sli_port(0..31)_pkind[pkind]決定的，現在猜想wqe中的pknd不是xuia的pkind決定的，而是獲取這個包的ring決定的，
要 1、確定ring和pkind的對映關係 2、ring和xuia口的對映關係 找到這兩點就能將不同的pkind和不同的xuia介面聯絡起來
獲得資訊：
1、ring和pkind的對映關係在這個暫存器中儲存：sli_port(0..31)_pkind[pkind]
2、每個dpi ring都會對映到乙個pip/ipd pkind，對映關係在
sli_port(0..31)_pkind[pkind] 儲存
說明ring的pkind和xaui介面的pkind是一樣的
qos：由
pip_prt_tag[pkind]暫存器決定，這是預設配置，我們沒有對預設配置進行修改，pkind怎麼產生的暫時沒找到（因為列印資訊的pkind是0，1，2，3；qos也是0，1，2，3；檢視
pip_prt_tag暫存器發現吻合，可以確定qos是文件上寫的預設的取法）
grp：在
include/mpp_init.c 中 mc_pip_port_intialize函式中，grep被顯式的設定為group_from_input_port，實際值為0
問題：咱們的包型別是剝離兩層頭的型別？
cdk3核心中的函式（mc開頭的）在執行的時候會被更新到響應呼叫它的位置上。如何移動的這些函式？
標準輸入流
get 從流中提取字元，包括空格 read 無格式輸入指定位元組數 getline 從流中提取一行字元 ignore 提取並丟棄流中指定字元 peek 返回流中下乙個字元，但不從流中刪除 gcount 統計最後輸入的字元個數 seekg 移動輸入流指標 int get cin.get char rc...
緩衝輸入流
快取輸入流 bufferedinputstream繼承於filterinputstream，提供緩衝輸入流功能。緩衝輸入流相對於普通輸入流的優勢是，它提供了乙個緩衝陣列，每次呼叫read方法的時候，它首先嘗試從緩衝區裡讀取資料，若讀取失敗 緩衝區無可讀資料 則選擇從物理資料來源 譬如檔案 讀取新資料...
GoFuzz自定義語料輸入流程 記錄
在使用gofuzz的過程中，發現自己輸入的corpus好像沒有被執行。遂審計一下 追蹤一下輸入的corpus的處理流程。在一次測試過程中，我輸入的初始語料如下 但進化出的可崩潰語料卻是這些 t 00 0 這都是嘛玩意兒，根本看不出跟我的初始輸入有啥血緣關係。於是跟進一下 來學習一下corpus的處理...