Re: [心得] 系統廠軟體工程師跟軟體工程師是兩回事...

[rawpacket (rawpacket)]

※ 引述《iincho (世界的盡頭)》之銘言：
: : 7. 沒有軟體服務的觀念...
: : 8. 沒有 debugger 觀念... 除錯常用 printf...
: : 我覺得最扯的是主管還幫我們定Schedule...
: : 只要Schedule不是自己定的... 通常是不符實際...
: : 然後系統廠工程師真的都自我感覺超良好...
: : 還很強調他當年在系統廠的經驗... 可是軟體就真的不是那樣的...
:   系統廠的RD最強的就是看方塊圖slide和插log，做完AB Test之後
:   打電話call vendor，你上面講的東西很多人不是不會而是....
:   當你發現printf比debugger快的時候你選哪個...XD?
:   媽啦trace32剛上去別人就靠看log解完了，根本沒效益啊.
:   你這狀況八成是主管原本就是搞偏硬的，所以這些觀念一時
:   改不過來，這些觀念再純軟基本上會有衝突的。
:   至於schedule，主管抓有主管抓的好處，你這個問題是主管不懂
:   這個domain還硬開當然爆光光，不是系統廠不系統廠的問題。
:   為什麼通常系統廠會這樣，因為客戶最大，你的schedule是為了
:   滿足客戶需求，做不到你也得乖乖的加班加到爆。

系統廠搞什麼 OO C++
基本上系統廠就是搞硬體的, 將自己想像成搞軟體的是想怎麼樣?

這業界的生態是這樣. (隨便舉例)


   IC Vednor  --> 系統廠 ------>  Software Vendor  --> End customer
   提供 IC.       整合各家 IC     出上層的 Software
                  出 BSP


   如果 Software Vendor 是 Google 的 Andoird or Linux kernel
   那圖大概就變成

   Software Vendor -> IC Vendor -> 系統廠 -> End Customer

在這一圈內, 系統廠最重要的就是整合,
整合 IC Vendor 提供的功能, 整合 Software Vendor 的 solution .
簡單的說, 別人有人什麼, 你整合什麼.
整合的功能是 End customer 提供的.

ex:
End Customer 說我要 Raid 5 ..
系統廠就要負責去弄好 Linux kernel + SATA + MD Layer + GUI
如果中間有 Raid software vendor .
那 software vendor 就要處理好 MD Layer + GUI
系統廠要負責 Linux kernel + SATA

老實說, 純軟體的也不一定會用 Trace32 這種 debug tool .
搞不好還是在用 gdb , GOD, gdb .. 那還是用 printf 好了....
而且 printf 練久了, 發現手感還會比較好.

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.113.22.92
→ dryman:gdb明明就很強...
→ final01:這篇一對名詞 是想顯得很專業嗎?
推 dwi2:系統廠就是一堆這樣的名詞
推 smi1e:gdb有啥不好...
→ latw:糟糕,我都不用printf,我只有printk可以用...(逃)
推 lauto:交出去的東西符合客戶需求 用printf/gdb有差嗎
推 lauto:我是挑順手的來用 能幫助我解bug的就是好工具
→ remmurds:認同 工具只是工具 用得順手才重要
推 yamikiri:樓樓樓樓上的是寫linux driver的XD
推 Neo1978:最可怕的事情是加了printf/printk bug會不見....
推 jackcorner:樓上我懂XD (握~
加了 Bug 會不見表示你們不知道 Bug 在那邊.
如果有這種狀況, 八成是 hardware timing issue.
找 hardware 出來量訊號看看...
→ iincho:不對，kernel有很多地方是不能printk的...
基本上 kernel 不能 printk 可以用 debug tool.
不過有些狀況有 debug tool 也不一定幫得上忙就是了.
一介入速度變慢就不會出來
推 Kerick:系統廠SA做上層APP 純軟體工程師 可能會有OO C++...
→ iincho:SA目前好像比較少搞自己客製化的東西, bundle比較多(?
推 john0312:gdb很棒啊. 最早擁有Reversible Debugging的就是gcc.
→ john0312:平台支援跟語言支援也是最好的. 只是文字介面新手不習慣.
→ iincho:嗯..看看WinDBG, 在看看gdb....(轉頭
還有 ddd.... (還是很難用 XD)
推 popoblue:可是系統廠的老油條會懷疑你想的是否有用... 然後不用
※ 編輯: rawpacket       來自: 140.113.22.92        (03/07 01:54)
推 i386:接觸到越底層硬體架構就越知道gdb的好用了...
→ i386:況且...支援gdb mi protocol的視窗debug軟體有一大堆吧..
→ iincho:底層XDD? 多底層?? RealDebug或是Trace32臭了嗎XDD?
→ iincho:樓上講gdb好用麻煩去看看人家WinDBG搞到什麼程度.....
推 i386:那樓上可能要先教我一下怎樣在Linux下裝WinDBG了...
→ i386:Trace32沒錯,功能很強大...但是一台也要不少錢就是了...
→ i386:如果公司每個軟體RD都配一台的話,我也不用GDB阿..
→ i386:我接觸過最底層的是一顆全新的SoC剛設計出來還在RTL和FPGA
→ i386:驗證的階段...
→ iincho:那你也應該知道很多狀況GDB是沒用的, 有時連Linux都沒有..
→ iincho:說真的純比較debugger功能，gdb算是很爛的, 問題是你沒別的
→ iincho:可以選，所以一堆人會說gdb很好用...%@@#@