ข้ามไปที่เนื้อหาหลัก

Dynamic Kernel Module Support (DKMS) ภาค 1


Dynamic Kernel Module Support

ถ้าให้เล่าย้อนความเกี่ยวกับเจ้า DKMS ก็หลายปีมากเลยละ แต่จะสรุปให้ผู้อ่านดังนี้ คือ สมัยก่อนสำหรับคนเล่นลีนุกส์เวลาที่เราจะเพิ่มเติม ความสามารถ (feature) ให้กับ kernel นั้น เราจะต้อง patch kernel แล้วทำการคอมไพล์ Kernel ใหม่ทำการดาวน์โหลดไฟล์ kernel ที่ต้องการใช้ได้จาก https://www.kernel.org/ ซึ่ง kernel จากเว็บนี้เราจะเรียกกันว่า Vanilla Kernel 

ถ้าไม่เกริ่นเกี่ยวกับ Vanilla Kernel เดี่ยวจะงงสรุปสั้นคือ กลุ่มโปรแกรมเมอร์ที่พัฒนา kernel ให้เราใช้นี้และ โดยมีคุณไลนัส ทอร์วัลด์ส (Linus Benedict Torvalds) เป็นแกนนำ แล้วมันแตกต่างกับ Kernel ที่เราใช้บนระบบปฏิบัติการอื่นอย่างไร เช่น Debian, Redhat ฯลฯ

ความแตกต่างง่ายๆ ดังนี้

  • การเลือก Vanilla Kernel มาใช้นั้น แต่ละระบบปฏิบัติการมีแนวคิดต่างกัน ในการเลือกนำมาใช้โดยดูการ support ของแต่ละเวอร์ชั่น

  • โดยพวกระบบปฏิบัติการต่างๆ จะมีการวิธีการเลือกต่างๆ กัน เช่น เน้นรองรับความสามารถใหม่, รองรับฮาวด์แวร์ใหม่ ก็จะเลือกใช้ Kernel เวอร์ชั่นใหม่, เน้นความเสถียร ก็จะเลือก Kernel เวอร์ชั่นเก่า
  • พวกระบบปฏิบัติการต่างๆ ก็จะเอา Vanilla Kernel นี้และมาดูแลต่อเอง ไม่ว่าจะเป็นเรื่องรองรับอุปกรณ์ (Hardware), รองรับเรื่องความปลอดภัย (Security), รองรับเรื่องความสามารถใหม่ๆ (Feature)
  • โดยแต่ระบบปฏิบัติการการเอามารองรับนานแค่ไหน เราก็ต้องทำการดูแต่ระบบปฏิบัติการและเลือกเอาเอง
สรุปปิดท้าย เพื่อไม่ให้บทความยาวไปแล้วค่อยไปอ่านภาค 2 กันต่อ ที่ได้กล่าวมาตอนต้น การที่เราจะเอา vanilla kernel มาเพิ่มความสามารถ หรือปรับแก้ไขตามความต้องการของเรานั้น มันมีข้อเสียดังนี้ เวลาที่ใช้คอมไพล์นาน, การดูแลในด้านความปลอดภัยทั้งบักหรือช่องโหว่ โดยถ้าเราไม่มีทีมดูแลเฉพาะทางด้วยแล้ว ไม่ควรอย่างยิ่งที่จะทำ ฯลฯ ทำให้มีแนวคิดว่า ทำไมไม่ทำให้มัน dynamic kernel module ได้ละ คือ โหลดตอนที่ต้องการเรียกใช้งาน หรือ คอมไพล์ในส่วนที่เราต้องการเพิ่มใช้พอ โดยไม่ต้องทำการคอมไพล์ทั้ง kernel ใหม่ทั้งหมด

ความคิดเห็น

โพสต์ยอดนิยมจากบล็อกนี้

System Analyst สำคัญฉะไหน

ถ้าคุณเจอปัญหาเหล่านี้ มาลองให้ความสำคัญกับ System Analyst แล้วจะรู้ว่าคุณเข้าใจผิดเกี่ยวกับหน้าที่ของ SA โปรเจคที่พัฒนาล้มเหลว โปรเจคที่พัฒนาออกแบบไม่ตรงตามความต้องลูกค้า โปรเจคที่พัฒนาไม่เสร็จตามกำหนดเวลา โปรเจคที่พัฒนาต้นทุนบานปลาย โปรเจคที่พัฒนาเลือกใช้เทคโนโลยีผิด และอื่นๆ อีกมากมายที่ซอฟต์แวร์หรือระบบที่พัฒนาไม่ประสบความสำเร็จ สิ่งที่ System Analyst ต้องมี ประสบการณ์ (เจ้าข้อนี้และที่เข้าใจผิดกันเยอะ) SA ที่ดีต้องเคยเขียนหรือพัฒนาโปรแกรมมาก่อนหรือก็คือ เป็นโปรแกรมเมอร์มาก่อน SA ที่ดีต้องเคยต้องเคยออกแบบฐานข้อมูล SA ที่ดีต้องเคยวิเคราะห์และออกแบบระบบงานเกี่ยวกับธุรกิจมาเยอะพอสมควร SA ที่ดีต้องเขียนและอธิบายเอกสารได้ ตามหลักสากลนะ รอบรู้  มีความรู้เกี่ยวกับเทคโนโลยีต่างๆ แค่รู้ไม่จำเป็นต้องชำนาญ มีความเข้าใจเกี่ยวกับระบบงานของธุรกิจต่างๆ เป็นอย่างดี เข้าใจขั้นตอนการพัฒนาซอฟต์แวร์ตามหลักการพัฒนา System development Life Cycle (SDLC) เข้าใจขั้นตอนการพัฒนาซอฟต์แวร์แบบอื่นๆ เช่น Agile เป็นต้น รอบคอบและเฉลียวฉลาด ข้อนี้จะเกิดได้ ก็จากสองอันแรก ...

Dynamic Kernel Module Support (DKMS) ภาค 3

Dynamic Kernel Module Support เกริ่นมา 2 บทความแล้ว หวังว่าผู้อ่านจะเข้าใจนะครับ สรุปง่ายๆ คือ เจ้าพระเอกของเรา DKMS คำสั่งนี้จะช่วยให้เราจะทำการไฟล์ติดตั้งไดว์เวอร์ให้เราอัตโนมัติ เมื่อมีการอัพเดต kernel ให้เรา ทำให้เราไม่เจอปัญหาเวลาอัพเดตระบบปฏิบัติการแล้วใช้งานไดว์เวอร์การ์ดแลนได้ ปล. มันไม่ใช้แค่ช่วยเรื่องไดว์เวอร์ ยังช่วยทำให้เราเพิ่มความสามารถให้กับ kernel อีกด้วย ขั้นตอนการทำดังนี้ ก่อนทำ เราจะเช็คดูก่อนเพื่อสำรองไฟล์เดิมหรือทำการเช็คเวอร์ชั่นที่ใช้อยู่ได้ เช่น modinfo e1000e (เช็คตำแหน่งที่เก็บไฟล์ไดว์เวอร์) ethtool eth0 (ดูเวอร์ชั่นของไดว์เวอร์) ฯลฯ สามารถใช้ผู้ใช้งาน root ในการทำได้  และก่อนทำบนเครื่องต้องมีคำสั่งและ kernel header ด้วยในที่นี้ผู้เขียนทำตัวอย่างบนระบบปฏิบัติการ Debian ก็ได้ทำการติดตั้งดังนี้  apt-get install dkms deb-helper build-essential linux-headers-$(uname -r) make  cd /usr/src/ sudo wget https://downloadmirror.intel.com/15817/eng/e1000e-3.4.0.2.tar.gz sudo tar xvfz e1000e-3.4.0.2.tar.gz cd e1000e-3.4.0.2 sudo ...

ขั้นตอนวางแผนการทำงาน Waterfall step 1

Waterfall Model ขั้นตอนที่ 1 การวางแผนการทำงาน กำหนดหัวข้อในการทำงาน โดยส่วนนี้เราจะเน้นหัวข้อสำคัญใหญ่ๆ เท่านั้น กำหนดผู้รับผิดชอบในการทำงานเบื้องต้น กำหนดระยะเวลาการทำงาน เป็นไปไม่ได้เลยที่เราจะทำงานไปเรื่อยๆ ไม่มีกำหนดเวลาเสร็จ เพราะการใช้ระยะเวลาทำงานยิ่งนานก็ยิ่งมีต้นทุนค่าใช้จ่ายมากขึ้น จากรูปด้านบนจะเป็นแผนภาพแกรนท์ (Gantt Chart) จะเป็นแผนผังควบคุมกิจกรรมต่างๆ ให้ทำงานอยู่ในกรอบเวลาที่กำหนด ซึ่งในส่วนนี้ทาง  System Analyst (SA) จะได้รับข้อมูลจากทาง SALE / Project Manager ในเรื่องขอบเขตของระยะเวลาในการทำงานและการส่งมอบงาน เพื่อใช้ในการวางแผน ประชุม กับทีมงานพัฒนาเพื่อกำหนดหัวข้อ ระยะเวลา และผู้รับผิดชอบ อ่านตอน 2 ได้ที่  https://thaidevnote.blogspot.com/2018/04/waterfall-step-2.html