ในวิทยาการคอมพิวเตอร์ไมโครเคอร์เนล (มักย่อว่าμ-kernel ) คือ ซอฟต์แวร์ที่มีขนาดเล็กที่สุดเท่าที่จะเป็นไปได้ซึ่งสามารถจัดเตรียมกลไกที่จำเป็นในการใช้งานระบบปฏิบัติการ (OS) กลไกเหล่านี้รวมถึง การจัดการพื้นที่แอดเดรสระดับต่ำ การจัดการ เธรดและการสื่อสารระหว่างกระบวนการ (IPC)

หากฮาร์ดแวร์มีวงแหวนหรือโหมด CPU หลายแบบ ไมโครเคอร์เนลอาจเป็นซอฟต์แวร์เพียงตัวเดียวที่ทำงานในระดับที่มีสิทธิ์สูงสุด ซึ่งโดยทั่วไปเรียกว่าโหมดผู้ดูแลระบบหรือโหมดเคอร์เนลฟังก์ชันระบบปฏิบัติการแบบดั้งเดิม เช่นไดรเวอร์อุปกรณ์สแต็กโปรโตคอลและระบบไฟล์มักจะถูกแยกออกจากไมโครเคอร์เนลและทำงานในพื้นที่ผู้ใช้แทน^{[ 1 ]}

โดยทั่วไปแล้วไมโครเคอร์เนลจะมีซอร์สโค้ดน้อยกว่าเคอร์เนลแบบโมโนลิธิก ตัวอย่างเช่น ไมโครเคอร์เนล MINIX 3มีโค้ดเพียงประมาณ 12,000 บรรทัด^{[ 2 ]}

ไมโครเคอร์เนลมีต้นกำเนิดมาจากPer Brinch Hansen ผู้บุกเบิกคอมพิวเตอร์ชาวเดนมาร์ก และช่วงเวลาที่เขาทำงานในบริษัทคอมพิวเตอร์Regnecentralen ของเดนมาร์ก ซึ่งเขาเป็นผู้นำในการพัฒนาซอฟต์แวร์สำหรับคอมพิวเตอร์ RC 4000 ^{[ 3 ]}ในปี 1967 Regnecentralen ได้ติดตั้งต้นแบบ RC 4000 ใน โรงงานปุ๋ย Zakłady Azotowe Puławyในโปแลนด์ คอมพิวเตอร์ใช้ระบบปฏิบัติการแบบเรียลไทม์ขนาดเล็กที่ปรับแต่งให้เหมาะกับความต้องการของโรงงาน Brinch Hansen และทีมของเขากังวลเกี่ยวกับการขาดความทั่วไปและความสามารถในการนำกลับมาใช้ใหม่ของระบบ RC 4000 พวกเขากลัวว่าการติดตั้งแต่ละครั้งจะต้องใช้ระบบปฏิบัติการที่แตกต่างกัน ดังนั้นพวกเขาจึงตรวจสอบวิธีการสร้างซอฟต์แวร์สำหรับ RC 4000 ที่แปลกใหม่และทั่วไปมากขึ้น^{[ 4 ]} ในปี 1969 ความพยายามของพวกเขาส่งผลให้ระบบมัลติโปรแกรม มิ่งRC 4000 เสร็จสมบูรณ์แกนกลางของระบบนี้รองรับการสื่อสารระหว่างกระบวนการโดยอาศัยการส่งข้อความสำหรับกระบวนการที่ไม่ได้รับสิทธิ์สูงสุด 23 กระบวนการ โดยในแต่ละครั้งจะมี 8 กระบวนการที่ได้รับการปกป้องจากกันและกัน นอกจากนี้ยังมีการกำหนดตารางเวลาสำหรับช่วงเวลาการทำงานของโปรแกรมที่ทำงานแบบขนาน การเริ่มต้นและการควบคุมการทำงานของโปรแกรมตามคำขอของโปรแกรมอื่นที่กำลังทำงานอยู่ และการเริ่มต้นการถ่ายโอนข้อมูลไปยังหรือจากอุปกรณ์ต่อพ่วง นอกเหนือจากกลไกพื้นฐานเหล่านี้แล้ว ระบบนี้ไม่มีกลยุทธ์ในตัวสำหรับการทำงานของโปรแกรมและการจัดสรรทรัพยากร กลยุทธ์นี้จะต้องถูกนำไปใช้โดยลำดับชั้นของโปรแกรมที่กำลังทำงานอยู่ โดยที่กระบวนการแม่มีอำนาจควบคุมกระบวนการลูกอย่างสมบูรณ์และทำหน้าที่เป็นระบบปฏิบัติการของกระบวนการลูก^{[ 5 ] [ 6 ]}

จากผลงานของ Brinch Hansen ไมโครเคอร์เนลได้รับการพัฒนามาตั้งแต่ทศวรรษ 1970 ^{[ 7 ]}คำว่าไมโครเคอร์เนลปรากฏขึ้นครั้งแรกไม่เกินปี 1981 ^{[ 8 ]}ไมโครเคอร์เนลมีจุดประสงค์เพื่อตอบสนองต่อการเปลี่ยนแปลงในโลกของคอมพิวเตอร์ และต่อความท้าทายหลายประการในการปรับ " โมโนเคอร์เนล " ที่มีอยู่ให้เข้ากับระบบใหม่เหล่านี้ ไดรเวอร์อุปกรณ์ใหม่ สแต็กโปรโตคอล ระบบไฟล์ และระบบระดับต่ำอื่นๆ กำลังได้รับการพัฒนาอยู่ตลอดเวลา โค้ดเหล่านี้มักจะอยู่ในเคอร์เนล แบบโมโนลิธิก ดังนั้นจึงต้องใช้ความพยายามอย่างมากและการจัดการโค้ดอย่างระมัดระวังในการทำงาน ไมโครเคอร์เนลได้รับการพัฒนาโดยมีแนวคิดว่าบริการทั้งหมดเหล่านี้จะถูกนำไปใช้เป็นโปรแกรมในพื้นที่ผู้ใช้ เช่นเดียวกับโปรแกรมอื่นๆ ทำให้สามารถทำงานแบบโมโนลิธิกและเริ่มต้นและหยุดได้เหมือนโปรแกรมอื่นๆ ซึ่งไม่เพียงแต่จะทำให้สามารถทำงานกับบริการเหล่านี้ได้ง่ายขึ้นเท่านั้น แต่ยังแยกโค้ดเคอร์เนลออกเพื่อให้สามารถปรับแต่งได้อย่างละเอียดโดยไม่ต้องกังวลเกี่ยวกับผลข้างเคียงที่ไม่ได้ตั้งใจ นอกจากนี้ยังช่วยให้สามารถ "สร้าง" ระบบปฏิบัติการใหม่ทั้งหมดบนแกนหลักทั่วไป ซึ่งช่วยในการวิจัยระบบปฏิบัติการ

ไมโครเคอร์เนลเป็นหัวข้อที่ได้รับความสนใจอย่างมากในช่วงทศวรรษ 1980 เมื่อมีการนำเครือข่ายท้องถิ่น ที่ใช้งานได้จริงมาใช้เป็นครั้งแรก ^{[ 9 ]} เคอร์เนล AmigaOS Execเป็นตัวอย่างแรกๆ ที่เปิดตัวในปี 1986 และใช้ในพีซีที่ประสบความสำเร็จในเชิงพาณิชย์พอสมควร การขาดการป้องกันหน่วยความจำ ซึ่งในด้านอื่นๆ ถือว่าเป็นข้อบกพร่อง ทำให้เคอร์เนลนี้มีประสิทธิภาพในการส่งข้อความสูง เนื่องจากไม่จำเป็นต้องคัดลอกข้อมูลในขณะที่แลกเปลี่ยนข้อความระหว่างโปรแกรมในพื้นที่ผู้ใช้^{[ 10 ]}

กลไกเดียวกันที่อนุญาตให้เคอร์เนลกระจายไปยังพื้นที่ผู้ใช้ยังอนุญาตให้ระบบกระจายผ่านลิงก์เครือข่ายได้ด้วย ไมโครเคอร์เนลรุ่นแรกๆ โดยเฉพาะMachที่สร้างโดยRichard Rashidพิสูจน์แล้วว่ามีประสิทธิภาพที่น่าผิดหวัง แต่ข้อดีโดยธรรมชาติปรากฏให้เห็นอย่างมากจนกลายเป็นแนวทางการวิจัยหลักในช่วงปลายทศวรรษ 1990 ^{[ 11 ]}อย่างไรก็ตาม ในช่วงเวลานี้ ความเร็วของคอมพิวเตอร์เพิ่มขึ้นอย่างมากเมื่อเทียบกับระบบเครือข่าย และข้อเสียในด้านประสิทธิภาพก็กลายเป็นสิ่งที่บดบังข้อดีในแง่ของการพัฒนา

มีความพยายามมากมายในการปรับระบบที่มีอยู่ให้มีประสิทธิภาพที่ดีขึ้น แต่ค่าใช้จ่ายมักจะสูงมาก และความพยายามส่วนใหญ่เหล่านี้จำเป็นต้องย้ายโปรแกรมในพื้นที่ผู้ใช้กลับเข้าไปในเคอร์เนล ภายในปี 2000 ความพยายามในการพัฒนาเคอร์เนล Mach ขนาดใหญ่ส่วนใหญ่ได้สิ้นสุดลงแล้ว แม้ว่าmacOS ของ Apple ซึ่งเปิดตัวในปี 2001 ยังคงใช้เคอร์เนลแบบไฮบริดที่เรียกว่าXNUซึ่งรวมเคอร์เนล Mach ของOSF/1 ที่ได้รับการดัดแปลงอย่างมาก (ไฮบริด) (เคอร์เนล OSF MK 7.3) เข้ากับโค้ดจาก BSD UNIX ^{[ 12 ] [ 13 ]}เคอร์เนลนี้ยังใช้ในiOS , tvOSและwatchOS ด้วย Windows NTตั้งแต่NT 3.1ไปจนถึงWindows 11 ใช้การออกแบบเคอร์เนลแบบไฮบริด ณ ปี 2012 GNU Hurdที่ใช้ Mach ก็ใช้งานได้และรวมอยู่ในเวอร์ชันทดสอบของArch LinuxและDebianด้วย

แม้ว่างานหลักเกี่ยวกับไมโครเคอร์เนลจะสิ้นสุดลงไปแล้วเป็นส่วนใหญ่ แต่นักทดลองก็ยังคงพัฒนาต่อไป^{[ 14 ] [ 15 ]}การใช้แนวทางที่เป็นรูปธรรมมากขึ้นในการแก้ปัญหา รวมถึง การใช้ โค้ดแอสเซมบลีและการพึ่งพาโปรเซสเซอร์ในการบังคับใช้แนวคิดที่ปกติแล้วรองรับในซอฟต์แวร์ นำไปสู่ไมโครเคอร์เนลชุดใหม่ที่มีประสิทธิภาพดีขึ้นอย่างมาก

ไมโครเคอร์เนลมีความเกี่ยวข้องอย่างใกล้ชิดกับเอ็กโซเคอร์เนล [ ^{16 ] นอกจาก}นี้ยังมีความคล้ายคลึงกับไฮเปอร์ไวเซอร์มาก^{[ 17 ]}แต่ไฮเปอร์ไวเซอร์ไม่ได้อ้างว่ามีความเรียบง่ายและมีความเชี่ยวชาญในการสนับสนุนเครื่องเสมือนไมโครเคอร์เนล L4มักถูกนำไปใช้ในฐานะไฮเปอร์ไวเซอร์

เคอร์เนลของระบบปฏิบัติการในยุคแรกมีขนาดค่อนข้างเล็ก ส่วนหนึ่งเป็นเพราะหน่วยความจำของคอมพิวเตอร์มีจำกัด เมื่อความสามารถของคอมพิวเตอร์เพิ่มขึ้น จำนวนอุปกรณ์ที่เคอร์เนลต้องควบคุมก็เพิ่มขึ้นตามไปด้วย ตลอดช่วงประวัติศาสตร์ยุคแรกของUnixเคอร์เนลโดยทั่วไปมีขนาดเล็ก แม้ว่าจะประกอบด้วยไดรเวอร์อุปกรณ์และระบบไฟล์ ต่างๆ มากมาย ก็ตาม เมื่อพื้นที่แอดเดรสเพิ่มขึ้นจาก 16 บิตเป็น 32 บิต การออกแบบเคอร์เนลก็ไม่ถูกจำกัดด้วยสถาปัตยกรรมฮาร์ดแวร์อีกต่อไป และเคอร์เนลก็มีขนาดใหญ่ขึ้น

ระบบปฏิบัติการ Berkeley Software Distribution (BSD) ของUnixได้เริ่มต้นยุคของเคอร์เนลขนาดใหญ่ขึ้น นอกเหนือจากการทำงานของระบบพื้นฐานที่ประกอบด้วย CPU ดิสก์ และเครื่องพิมพ์แล้ว BSD ยังเพิ่มระบบเครือข่าย TCP/IP ที่สมบูรณ์ และอุปกรณ์ "เสมือน" จำนวนมากที่ช่วยให้โปรแกรมที่มีอยู่ทำงานได้อย่าง "มองไม่เห็น" ผ่านเครือข่าย การเติบโตนี้ดำเนินต่อไปเป็นเวลาหลายปี ส่งผลให้เคอร์เนลมี ซอร์สโค้ดหลายล้านบรรทัดผลจากการเติบโตนี้ เคอร์เนลจึงมีแนวโน้มที่จะเกิดข้อผิดพลาดและดูแลรักษายากขึ้นเรื่อยๆ

ไมโครเคอร์เนลถูกออกแบบมาเพื่อแก้ปัญหาการเติบโตของเคอร์เนลและความยากลำบากที่เกิดขึ้น ในทางทฤษฎี การออกแบบไมโครเคอร์เนลช่วยให้การจัดการโค้ดง่ายขึ้นเนื่องจากการแบ่งออกเป็น บริการใน พื้นที่ผู้ใช้นอกจากนี้ยังช่วยเพิ่มความปลอดภัยและความเสถียรเนื่องจากปริมาณโค้ดที่ทำงานในโหมดเคอร์เนล ลดลง ตัวอย่างเช่น หากบริการเครือข่ายล่มเนื่องจากบัฟเฟอร์โอเวอร์โฟลว์เฉพาะหน่วยความจำของบริการเครือข่ายเท่านั้นที่จะเสียหาย ส่วนที่เหลือของระบบยังคงทำงานได้

การสื่อสารระหว่างกระบวนการ (IPC) คือกลไกใดๆ ที่อนุญาตให้กระบวนการที่แยกจากกันสื่อสารกันได้ โดยปกติแล้วจะใช้วิธีส่งข้อความหน่วยความจำที่ใช้ร่วมกัน (Shared memory)ก็ถือเป็นกลไกการสื่อสารระหว่างกระบวนการเช่นกัน แต่โดยทั่วไปแล้ว IPC มักหมายถึงการส่งข้อความเท่านั้น และอย่างหลังนี้มีความเกี่ยวข้องอย่างยิ่งกับไมโครเคอร์เนล IPC ช่วยให้ระบบปฏิบัติการสามารถสร้างขึ้นจากโปรแกรมขนาดเล็กจำนวนมากที่เรียกว่าเซิร์ฟเวอร์ ซึ่งโปรแกรมอื่นๆ ในระบบจะใช้งานโดยเรียกใช้ผ่าน IPC การสนับสนุนฮาร์ดแวร์อุปกรณ์ต่อพ่วงส่วนใหญ่หรือทั้งหมดจะจัดการในลักษณะนี้ โดยมีเซิร์ฟเวอร์สำหรับไดรเวอร์อุปกรณ์สแต็กโปรโตคอลเครือข่ายระบบไฟล์ กราฟิก ฯลฯ

การสื่อสารระหว่างกระบวนการ (IPC) สามารถเป็นได้ทั้งแบบซิงโครนัสและอะซิงโครนัส การสื่อสารระหว่างกระบวนการแบบอะซิงโครนัสคล้ายกับการสื่อสารผ่านเครือข่าย กล่าวคือ ผู้ส่งส่งข้อความและดำเนินการต่อไป ผู้รับตรวจสอบ ( สำรวจ ) ว่าข้อความพร้อมใช้งานหรือไม่ หรือได้รับการแจ้งเตือนผ่านกลไกการแจ้งเตือนบางอย่าง การสื่อสารระหว่างกระบวนการแบบอะซิงโครนัสต้องการให้เคอร์เนลดูแลบัฟเฟอร์และคิวสำหรับข้อความ และจัดการกับบัฟเฟอร์ล้น นอกจากนี้ยังต้องการการคัดลอกข้อความสองครั้ง (จากผู้ส่งไปยังเคอร์เนลและจากเคอร์เนลไปยังผู้รับ) ในการสื่อสารระหว่างกระบวนการแบบซิงโครนัส ฝ่ายแรก (ผู้ส่งหรือผู้รับ) จะรอจนกว่าอีกฝ่ายพร้อมที่จะดำเนินการสื่อสารระหว่างกระบวนการ ไม่จำเป็นต้องใช้บัฟเฟอร์หรือการคัดลอกหลายครั้ง แต่การนัดพบโดยปริยายอาจทำให้การเขียนโปรแกรมยุ่งยาก โปรแกรมเมอร์ส่วนใหญ่จึงนิยมใช้การส่งแบบอะซิงโครนัสและการรับแบบซิงโครนัส

ไมโครเคอร์เนลรุ่นแรกมักรองรับทั้ง IPC แบบซิงโครนัสและอะซิงโครนัส และประสบปัญหาประสิทธิภาพ IPC ที่ต่ำโจเชน ลีดท์เคอสันนิษฐานว่าการออกแบบและการใช้งานกลไก IPC เป็นสาเหตุหลักของประสิทธิภาพที่ต่ำนี้ ในไมโครเคอร์เนล L4 ของเขา เขาได้บุกเบิกวิธีการที่ลดต้นทุน IPC ลงได้ถึงหนึ่งลำดับ [ ^{18 ]}ซึ่งรวมถึงการเรียกใช้ระบบ IPC ที่รองรับทั้งการส่งและการรับ ทำให้ IPC ทั้งหมดเป็นแบบซิงโครนัส และส่งข้อมูลให้มากที่สุดเท่าที่จะเป็นไปได้ในรีจิสเตอร์ นอกจากนี้ ลีดท์เคอยังได้แนะนำแนวคิดของ^การสลับกระบวนการโดยตรงซึ่งในระหว่างการดำเนินการ IPC จะมี การสลับบริบท (ไม่สมบูรณ์) จากผู้ส่งไปยังผู้รับโดยตรง หากส่วนหนึ่งหรือทั้งหมดของข้อความถูกส่งผ่านในรีจิสเตอร์ เช่นเดียวกับใน L4 การถ่ายโอนส่วนของข้อความในรีจิสเตอร์นี้จะทำได้โดยไม่ต้องคัดลอกเลย นอกจากนี้ยังหลีกเลี่ยงค่าใช้จ่ายในการเรียกใช้ตัวกำหนดตารางเวลาได้อีกด้วย วิธีนี้มีประโยชน์อย่างยิ่งในกรณีทั่วไปที่ใช้ IPC ใน ลักษณะ การเรียกใช้ฟังก์ชันระยะไกล (RPC) โดยไคลเอ็นต์เรียกใช้เซิร์ฟเวอร์ การปรับปรุงประสิทธิภาพอีกอย่างหนึ่งที่เรียกว่า การจัดตารางเวลา แบบขี้เกียจ (lazy scheduling ) จะหลีกเลี่ยงการวนดูคิวการจัดตารางเวลาในระหว่าง IPC โดยปล่อยให้เธรดที่บล็อกในระหว่าง IPC อยู่ในคิวพร้อมทำงาน เมื่อตัวจัดตารางเวลาถูกเรียกใช้ มันจะย้ายเธรดเหล่านั้นไปยังคิวรอที่เหมาะสม เนื่องจากในหลายกรณีเธรดจะถูกปลดบล็อกก่อนการเรียกใช้ตัวจัดตารางเวลาครั้งถัดไป วิธีนี้จึงช่วยประหยัดงานได้อย่างมากQNXและMINIX 3 ได้นำวิธีการที่คล้ายกันนี้มาใช้ แล้ว

ในการทดลองชุดหนึ่ง Chen และ Bershad ได้เปรียบเทียบจำนวนรอบหน่วยความจำต่อคำสั่ง (MCPI) ของUltrix แบบโมโนลิธิ กกับของMach แบบไมโครเคอร์เนล ที่รวมกับ เซิร์ฟเวอร์ Unix 4.3BSD ที่ทำงานในพื้นที่ผู้ใช้ผลลัพธ์ของพวกเขาอธิบายประสิทธิภาพที่แย่กว่าของ Mach ด้วย MCPI ที่สูงกว่า และแสดงให้เห็นว่า IPC เพียงอย่างเดียวไม่ได้เป็นสาเหตุหลักของโอเวอร์เฮดของระบบ ซึ่งชี้ให้เห็นว่าการเพิ่มประสิทธิภาพที่มุ่งเน้นเฉพาะ IPC จะมีผลจำกัด^{[ 19 ]}ต่อมา Liedtke ได้ปรับปรุงผลลัพธ์ของ Chen และ Bershad โดยสังเกตว่าความแตกต่างส่วนใหญ่ระหว่าง MCPI ของ Ultrix และ Mach เกิดจากการพลาดแคช ความจุ และสรุปว่าการลดชุดการทำงานของแคชของไมโครเคอร์เนลลงอย่างมากจะช่วยแก้ปัญหานี้ได้^{[ 20 ]}

In a client-server system, most communication is essentially synchronous, even if using asynchronous primitives, as the typical operation is a client invoking a server and then waiting for a reply. As it also lends itself to more efficient implementation, most microkernels generally followed L4's lead and only provided a synchronous IPC primitive. Asynchronous IPC could be implemented on top by using helper threads. However, experience has shown that the utility of synchronous IPC is dubious: synchronous IPC forces a multi-threaded design onto otherwise simple systems, with the resulting synchronization complexities. Moreover, an RPC-like server invocation sequentializes client and server, which should be avoided if they are running on separate cores. Versions of L4 deployed in commercial products have therefore found it necessary to add an asynchronous notification mechanism to better support asynchronous communication. This signal-like mechanism does not carry data and therefore does not require buffering by the kernel. By having two forms of IPC, they have nonetheless violated the principle of minimality. Other versions of L4 have switched to asynchronous IPC completely.^[21]

As synchronous IPC blocks the first party until the other is ready, unrestricted use could easily lead to deadlocks. Furthermore, a client could easily mount a denial-of-service attack on a server by sending a request and never attempting to receive the reply. Therefore, synchronous IPC must provide a means to prevent indefinite blocking. Many microkernels provide timeouts on IPC calls, which limit the blocking time. In practice, choosing sensible timeout values is difficult, and systems almost inevitably use infinite timeouts for clients and zero timeouts for servers. As a consequence, the trend is towards not providing arbitrary timeouts, but only a flag which indicates that the IPC should fail immediately if the partner is not ready. This approach effectively provides a choice of the two timeout values of zero and infinity. Recent versions of L4 and MINIX have gone down this path (older versions of L4 used timeouts). QNX avoids the problem by requiring the client to specify the reply buffer as part of the message send call. When the server replies the kernel copies the data to the client's buffer, without having to wait for the client to receive the response explicitly.^[22]

Microkernel servers are essentially daemon programs like any others, except that the kernel grants some of them privileges to interact with parts of physical memory that are otherwise off limits to most programs. This allows some servers, particularly device drivers, to interact directly with hardware.

ชุดเซิร์ฟเวอร์พื้นฐานสำหรับไมโครเคอร์เนลอเนกประสงค์ประกอบด้วยเซิร์ฟเวอร์ระบบไฟล์ เซิร์ฟเวอร์ไดรเวอร์อุปกรณ์ เซิร์ฟเวอร์เครือข่ายเซิร์ฟเวอร์แสดงผลและเซิร์ฟเวอร์อุปกรณ์ส่วนติดต่อผู้ใช้ ชุดเซิร์ฟเวอร์เหล่านี้ (ดึงมาจากQNX ) ให้บริการต่างๆ ที่คล้ายคลึงกับที่เคอร์เนลแบบโมโนลิธิก ของ Unix ให้ บริการ เซิร์ฟเวอร์ที่จำเป็นจะเริ่มต้นทำงานเมื่อระบบเริ่มทำงาน และให้บริการต่างๆ เช่น การเข้าถึงไฟล์ เครือข่าย และอุปกรณ์ แก่โปรแกรมแอปพลิเคชันทั่วไป ด้วยเซิร์ฟเวอร์เหล่านี้ที่ทำงานอยู่ในสภาพแวดล้อมของแอปพลิเคชันผู้ใช้ การพัฒนาเซิร์ฟเวอร์จึงคล้ายกับการพัฒนาแอปพลิเคชันทั่วไป มากกว่ากระบวนการสร้างและบูตที่จำเป็นสำหรับการพัฒนาเคอร์เนล

นอกจากนี้ “การขัดข้อง” จำนวนมากสามารถแก้ไขได้โดยการหยุดและเริ่มต้นเซิร์ฟเวอร์ใหม่ซึ่งจะไม่สามารถทำได้หากต้องรีบูตเคอร์เนลทั้งหมด อย่างไรก็ตาม สถานะระบบบางส่วนจะสูญหายไปพร้อมกับเซิร์ฟเวอร์ที่ล้มเหลว ดังนั้นวิธีการนี้จึงต้องการให้แอปพลิเคชันรับมือกับความล้มเหลว ตัวอย่างที่ดีคือเซิร์ฟเวอร์ที่รับผิดชอบ การเชื่อมต่อ TCP/IP : หากเซิร์ฟเวอร์นี้ถูกรีสตาร์ท แอปพลิเคชันจะประสบกับการเชื่อมต่อที่ “ขาดหาย” ซึ่งเป็นเหตุการณ์ปกติในระบบเครือข่าย สำหรับบริการอื่นๆ ความล้มเหลวนั้นคาดไม่ถึงและอาจต้องมีการเปลี่ยนแปลงโค้ดแอปพลิเคชัน สำหรับ QNX ความสามารถในการรีสตาร์ทมีให้ใน QNX High Availability Toolkit ^{[ 23 ]}

ไดรเวอร์อุปกรณ์มักทำการเข้าถึงหน่วยความจำโดยตรง (DMA) ดังนั้นจึงสามารถเขียนไปยังตำแหน่งใดก็ได้ในหน่วยความจำทางกายภาพ รวมถึงโครงสร้างข้อมูลเคอร์เนลต่างๆ ไดรเวอร์เหล่านี้จึงต้องได้รับความไว้วางใจ เป็นความเข้าใจผิดทั่วไปที่ว่านั่นหมายความว่าไดรเวอร์เหล่านั้นต้องเป็นส่วนหนึ่งของเคอร์เนล ในความเป็นจริงแล้ว การที่ไดรเวอร์เป็นส่วนหนึ่งของเคอร์เนลไม่ได้หมายความว่ามันน่าเชื่อถือมากกว่าหรือน้อยกว่ากัน

แม้ว่าการเรียกใช้ไดรเวอร์อุปกรณ์ในพื้นที่ผู้ใช้จะไม่จำเป็นต้องลดความเสียหายที่ไดรเวอร์ที่ทำงานผิดปกติอาจก่อให้เกิดได้ แต่ในทางปฏิบัติแล้วจะเป็นประโยชน์ต่อเสถียรภาพของระบบเมื่อมีไดรเวอร์ที่มีข้อบกพร่อง (มากกว่าไดรเวอร์ที่เป็นอันตราย) การละเมิดการเข้าถึงหน่วยความจำโดยโค้ดไดรเวอร์ (ตรงข้ามกับอุปกรณ์) อาจยังคงถูกตรวจจับได้โดยฮาร์ดแวร์การจัดการหน่วยความจำ นอกจากนี้ อุปกรณ์จำนวนมากไม่มีความสามารถในการใช้ DMA ไดรเวอร์ของอุปกรณ์เหล่านั้นสามารถทำให้ไม่น่าเชื่อถือได้โดยการเรียกใช้ในพื้นที่ผู้ใช้ เมื่อเร็วๆ นี้ คอมพิวเตอร์จำนวนมากขึ้นมีIOMMUซึ่งหลายตัวสามารถใช้เพื่อจำกัดการเข้าถึงหน่วยความจำทางกายภาพของอุปกรณ์ได้^{[ 24 ]}สิ่งนี้ยังช่วยให้ไดรเวอร์ในโหมดผู้ใช้ไม่น่าเชื่อถือได้อีกด้วย

ไดรเวอร์โหมดผู้ใช้มีมาก่อนไมโครเคอร์เนลเสียอีกระบบเทอร์มินัลมิชิแกน (MTS) ในปี 1967 รองรับไดรเวอร์ในพื้นที่ผู้ใช้ (รวมถึงการสนับสนุนระบบไฟล์) ซึ่งเป็นระบบปฏิบัติการแรกที่ได้รับการออกแบบด้วยความสามารถดังกล่าว^{[ 25 ]}ในอดีต ไดรเวอร์ไม่ใช่ปัญหาใหญ่ เนื่องจากจำนวนอุปกรณ์มีน้อยและเชื่อถือได้อยู่แล้ว การมีไดรเวอร์อยู่ในเคอร์เนลจึงช่วยลดความซับซ้อนของการออกแบบและหลีกเลี่ยงปัญหาประสิทธิภาพที่อาจเกิดขึ้นได้ สิ่งนี้ทำให้เกิดรูปแบบไดรเวอร์ในเคอร์เนลแบบดั้งเดิมของ Unix ^{[ 26 ]} Linux และ Windows NT เมื่ออุปกรณ์ต่อพ่วงชนิดต่างๆ แพร่หลายมากขึ้น ปริมาณโค้ดไดรเวอร์ก็เพิ่มขึ้น และในระบบปฏิบัติการสมัยใหม่ โค้ดไดรเวอร์มีขนาดใหญ่กว่าเคอร์เนลมาก

เนื่องจากไมโครเคอร์เนลต้องอนุญาตให้สร้างบริการระบบปฏิบัติการใดๆ ก็ได้ จึงต้องมีฟังก์ชันหลักบางอย่าง อย่างน้อยที่สุด ซึ่งรวมถึง:

• กลไกบางอย่างสำหรับการจัดการพื้นที่แอดเดรสซึ่งจำเป็นสำหรับการจัดการการป้องกันหน่วยความจำ
• มีการสร้างนามธรรมในการดำเนินการเพื่อจัดการการจัดสรร CPU โดยทั่วไปคือเธรดหรือการเปิดใช้งานตัวจัดตารางเวลา
• การสื่อสารระหว่างกระบวนการจำเป็นสำหรับการเรียกใช้เซิร์ฟเวอร์ที่ทำงานอยู่ในพื้นที่หน่วยความจำของตนเอง

การออกแบบที่เรียบง่ายนี้ริเริ่มโดยNucleusของBrinch Hansenและไฮเปอร์ไวเซอร์ของVM ของ IBM ต่อมาได้มีการกำหนดหลักการนี้อย่างเป็นทางการในหลักการความเรียบง่าย ของ Liedtke :

แนวคิดจะได้รับการยอมรับภายในไมโครเคอร์เนลก็ต่อเมื่อการย้ายแนวคิดนั้นออกไปนอกเคอร์เนล กล่าวคือ การอนุญาตให้มีการใช้งานที่แข่งขันกัน จะขัดขวางการใช้งานฟังก์ชันที่จำเป็นของระบบ^{[ 20 ]}

ส่วนอื่นๆ สามารถทำได้ในโปรแกรมโหมดผู้ใช้ แม้ว่าไดรเวอร์อุปกรณ์ที่ถูกใช้งานในรูปแบบโปรแกรมผู้ใช้ อาจต้องการสิทธิ์พิเศษในการเข้าถึงฮาร์ดแวร์ I/O บนสถาปัตยกรรมโปรเซสเซอร์บางแบบก็ตาม

หลักการที่เกี่ยวข้องกับความเรียบง่าย และมีความสำคัญเท่าเทียมกันสำหรับการออกแบบไมโครเคอร์เนล คือ การแยกกลไกและนโยบายซึ่งช่วยให้สามารถสร้างระบบใดๆ ก็ได้บนเคอร์เนลที่เรียบง่าย นโยบายใดๆ ที่สร้างขึ้นในเคอร์เนลไม่สามารถเขียนทับได้ในระดับผู้ใช้ ดังนั้นจึงจำกัดความทั่วไปของไมโครเคอร์เนล^{[ 16 ]}นโยบายที่นำไปใช้ในเซิร์ฟเวอร์ระดับผู้ใช้สามารถเปลี่ยนแปลงได้โดยการแทนที่เซิร์ฟเวอร์ (หรือให้แอปพลิเคชันเลือกระหว่างเซิร์ฟเวอร์ที่แข่งขันกันซึ่งให้บริการที่คล้ายคลึงกัน)

เพื่อให้เกิดประสิทธิภาพสูงสุด ไมโครเคอร์เนลส่วนใหญ่จึงมีตัวจัดตารางเวลาและจัดการตัวจับเวลา ซึ่งเป็นการฝ่าฝืนหลักการความเรียบง่ายและหลักการแยกนโยบายออกจากกลไก

การเริ่มต้น ( บูต ) ระบบที่ใช้ไมโครเคอร์เนลนั้นต้องการไดรเวอร์อุปกรณ์ซึ่งไม่ได้เป็นส่วนหนึ่งของเคอร์เนล โดยทั่วไปแล้ว หมายความว่าไดรเวอร์เหล่านั้นจะถูกบรรจุรวมกับเคอร์เนลในอิมเมจบูต และเคอร์เนลจะรองรับโปรโตคอลบูตสแตรปที่กำหนดวิธีการค้นหาและเริ่มต้นไดรเวอร์ ซึ่งเป็นขั้นตอนการบูตสแตรปแบบดั้งเดิมของไมโครเคอร์เนล L4 ไมโครเคอร์เนลบางตัว เช่นLynxOS และ Minixรุ่นดั้งเดิมทำให้กระบวนการนี้ง่ายขึ้นโดยการวางไดรเวอร์ที่สำคัญบางตัวไว้ภายในเคอร์เนล (ซึ่งเป็นการละเมิดหลักการความเรียบง่าย) บางตัวถึงกับรวมระบบไฟล์ ไว้ ในเคอร์เนลเพื่อทำให้การบูตง่ายขึ้น ระบบที่ใช้ไมโครเคอร์เนลอาจบูตผ่านบูตโหลดเดอร์ที่เข้ากันได้กับมัลติบูต ระบบดังกล่าวโดยทั่วไปจะโหลดเซิร์ฟเวอร์ที่เชื่อมโยงแบบคงที่เพื่อทำการบูตสแตรปเริ่มต้น หรือเมานต์อิมเมจระบบปฏิบัติการเพื่อดำเนินการบูตสแตรปต่อไป

องค์ประกอบสำคัญของไมโครเคอร์เนลคือ ระบบ IPC ที่ดี และการออกแบบตัวจัดการหน่วยความจำเสมือนที่ช่วยให้สามารถจัดการข้อผิดพลาดในการเข้าถึงหน้าหน่วยความจำและการสลับหน่วยความจำในเซิร์ฟเวอร์โหมดผู้ใช้ได้อย่างปลอดภัย เนื่องจากบริการทั้งหมดดำเนินการโดยโปรแกรมโหมดผู้ใช้ วิธีการสื่อสารที่มีประสิทธิภาพระหว่างโปรแกรมจึงมีความสำคัญอย่างยิ่ง มากกว่าในเคอร์เนลแบบโมโนลิธิก การออกแบบระบบ IPC เป็นตัวชี้ชะตาของไมโครเคอร์เนล เพื่อให้มีประสิทธิภาพ ระบบ IPC ไม่เพียงแต่ต้องมีค่าใช้จ่ายต่ำเท่านั้น แต่ยังต้องทำงานร่วมกับการจัดตารางเวลาของ CPU ได้ดีอีกด้วย

ในโปรเซสเซอร์หลักส่วนใหญ่ การรับบริการจะมีค่าใช้จ่ายสูงกว่าในระบบที่ใช้ไมโครเคอร์เนลมากกว่าระบบแบบโมโนลิธิก^{[ 16 ]}ในระบบแบบโมโนลิธิก การรับบริการจะทำได้โดยการเรียกใช้ระบบเพียงครั้งเดียว ซึ่งต้องมีการสลับโหมด สองครั้ง (การเปลี่ยน โหมดวงแหวนหรือโหมด CPUของโปรเซสเซอร์) ในระบบที่ใช้ไมโครเคอร์เนล การรับบริการจะทำได้โดยการส่งข้อความ IPC ไปยังเซิร์ฟเวอร์ และรับผลลัพธ์ในข้อความ IPC อีกข้อความหนึ่งจากเซิร์ฟเวอร์ ซึ่งต้องมีการสลับบริบทหากไดรเวอร์ถูกนำไปใช้เป็นกระบวนการ หรือการเรียกใช้ฟังก์ชันหากถูกนำไปใช้เป็นขั้นตอน นอกจากนี้ การส่งข้อมูลจริงไปยังเซิร์ฟเวอร์และส่งกลับอาจทำให้เกิดค่าใช้จ่ายในการคัดลอกเพิ่มเติม ในขณะที่ในระบบแบบโมโนลิธิก เคอร์เนลสามารถเข้าถึงข้อมูลในบัฟเฟอร์ของไคลเอ็นต์ได้โดยตรง

ดังนั้น ประสิทธิภาพจึงเป็นปัญหาที่อาจเกิดขึ้นในระบบไมโครเคอร์เนล ประสบการณ์ของไมโครเคอร์เนลรุ่นแรก เช่นMachและChorusOSแสดงให้เห็นว่าระบบที่ใช้ไมโครเคอร์เนลเหล่านี้มีประสิทธิภาพต่ำ^{[ 19 ]}อย่างไรก็ตามJochen Liedtkeแสดงให้เห็นว่าปัญหาด้านประสิทธิภาพของ Mach เป็นผลมาจากการออกแบบและการใช้งานที่ไม่ดี โดยเฉพาะอย่างยิ่งการใช้แคช มากเกินไปของ Mach ^{[ 20 ]} Liedtke ได้แสดงให้เห็นด้วย ไมโครเคอร์เนล L4ของเขาเองว่า ด้วยการออกแบบและการใช้งานอย่างระมัดระวัง และโดยเฉพาะอย่างยิ่งการปฏิบัติตามหลักการความเรียบง่าย ต้นทุน IPC สามารถลดลงได้มากกว่า Mach ถึงหนึ่งลำดับ ประสิทธิภาพ IPC ของ L4 ยังคงไม่มีใครเทียบได้ในสถาปัตยกรรมที่หลากหลาย^{[ 27 ] [ 28 ] [ 29 ]}

แม้ว่าผลลัพธ์เหล่านี้จะแสดงให้เห็นว่าประสิทธิภาพที่ไม่ดีของระบบที่ใช้ไมโครเคอร์เนลรุ่นแรกนั้นไม่เป็นตัวแทนของเคอร์เนลรุ่นที่สอง เช่น L4 แต่ก็ไม่ได้พิสูจน์ว่าระบบที่ใช้ไมโครเคอร์เนลสามารถสร้างได้ด้วยประสิทธิภาพที่ดี มีการแสดงให้เห็นแล้วว่าเซิร์ฟเวอร์ Linux แบบโมโนลิธิกที่พอร์ตไปยัง L4 มีค่าใช้จ่ายเพิ่มเติมเพียงไม่กี่เปอร์เซ็นต์เมื่อเทียบกับ Linux ดั้งเดิม^{[ 30 ]}อย่างไรก็ตาม ระบบเซิร์ฟเวอร์เดี่ยวดังกล่าวแสดงให้เห็นข้อดีเพียงเล็กน้อยหรือไม่มีเลยที่ไมโครเคอร์เนลควรจะมอบให้โดยการจัดโครงสร้างฟังก์ชันการทำงานของระบบปฏิบัติการลงในเซิร์ฟเวอร์แยกต่างหาก

มีระบบมัลติเซิร์ฟเวอร์เชิงพาณิชย์อยู่หลายระบบ โดยเฉพาะระบบเรียลไทม์QNXและIntegrityยังไม่มีการเผยแพร่การเปรียบเทียบประสิทธิภาพที่ครอบคลุมเมื่อเทียบกับระบบโมโนลิธิกสำหรับระบบมัลติเซิร์ฟเวอร์เหล่านั้น ยิ่งไปกว่านั้น ประสิทธิภาพดูเหมือนจะไม่ใช่สิ่งที่ระบบเชิงพาณิชย์เหล่านั้นให้ความสำคัญเป็นอันดับแรก แต่กลับเน้นที่เวลาตอบสนองการจัดการการขัดจังหวะที่รวดเร็วและเชื่อถือได้ (QNX) และความเรียบง่ายเพื่อความทนทาน ความพยายามในการสร้างระบบปฏิบัติการมัลติเซิร์ฟเวอร์ประสิทธิภาพสูงคือโครงการ IBM Sawmill Linux ^{[ 31 ]}อย่างไรก็ตาม โครงการนี้ไม่เคยเสร็จสมบูรณ์

ในระหว่างนี้ ได้มีการแสดงให้เห็นแล้วว่าไดรเวอร์อุปกรณ์ระดับผู้ใช้สามารถเข้าใกล้ประสิทธิภาพของไดรเวอร์ในเคอร์เนลได้ แม้แต่กับอุปกรณ์ที่มีปริมาณงานสูงและการขัดจังหวะสูง เช่น Gigabit Ethernet ^{[ 32 ]}ซึ่งดูเหมือนจะบ่งชี้ว่าระบบมัลติเซิร์ฟเวอร์ประสิทธิภาพสูงนั้นเป็นไปได้

ประโยชน์ด้านความปลอดภัยของไมโครเคอร์เนลได้รับการกล่าวถึงบ่อยครั้ง^{[ 33 ] [ 34 ]}ในบริบทของความปลอดภัย หลักการความเรียบง่ายของไมโครเคอร์เนลนั้น บางคนโต้แย้งว่าเป็นผลโดยตรงจากหลักการสิทธิ์ขั้นต่ำซึ่งระบุว่าโค้ดทั้งหมดควรมีสิทธิ์เฉพาะที่จำเป็นในการให้บริการตามที่ต้องการเท่านั้น ความเรียบง่ายกำหนดให้ฐานการประมวลผลที่เชื่อถือได้ (TCB) ของระบบควรมีขนาดเล็กที่สุด เนื่องจากเคอร์เนล (โค้ดที่ทำงานในโหมดสิทธิ์พิเศษของฮาร์ดแวร์) สามารถเข้าถึงข้อมูลใดๆ ได้โดยไม่ได้รับการตรวจสอบ และสามารถละเมิดความสมบูรณ์หรือความลับของข้อมูลได้ ดังนั้นเคอร์เนลจึงเป็นส่วนหนึ่งของ TCB เสมอ การลดขนาดเคอร์เนลจึงเป็นเรื่องปกติในการออกแบบที่เน้นความปลอดภัย

ด้วยเหตุนี้ การออกแบบไมโครเคอร์เนลจึงถูกนำมาใช้กับระบบที่ออกแบบมาสำหรับแอปพลิเคชันที่มีความปลอดภัยสูง รวมถึงKeyKOS , EROSและระบบทางทหาร อันที่จริงเกณฑ์ทั่วไป (CC) ในระดับการรับรองสูงสุด ( ระดับการรับรองการประเมิน (EAL) 7) มีข้อกำหนดที่ชัดเจนว่าเป้าหมายของการประเมินต้อง "เรียบง่าย" ซึ่งเป็นการยอมรับถึงความเป็นไปไม่ได้ในทางปฏิบัติที่จะสร้างความน่าเชื่อถือที่แท้จริงสำหรับระบบที่ซับซ้อน อีกครั้ง คำว่า "เรียบง่าย" นั้นทำให้เข้าใจผิดและไม่ชัดเจน อย่างน้อยเกณฑ์การประเมินระบบคอมพิวเตอร์ที่เชื่อถือได้ของกระทรวงกลาโหมก็ได้ใช้ถ้อยคำที่แม่นยำมากขึ้นในระดับ B3/A1:

"TCB จะต้อง [นำ] กลไกการป้องกันที่สมบูรณ์และเข้าใจง่ายมาใช้ โดยมีความหมายที่กำหนดไว้อย่างแม่นยำ วิศวกรรมระบบที่สำคัญจะต้องมุ่งเน้นไปที่การลดความซับซ้อนของ TCB ให้เหลือน้อยที่สุด ตลอดจนการตัดโมดูลที่ไม่สำคัญต่อการป้องกันออกจาก TCB"

ในปี 2018 เอกสารที่นำเสนอในการประชุม Asia-Pacific Systems Conference อ้างว่าไมโครเคอร์เนลมีความปลอดภัยกว่าเคอร์เนลแบบโมโนลิธิกอย่างเห็นได้ชัด โดยการตรวจสอบCVE ที่สำคัญทั้งหมดที่เผยแพร่ สำหรับ เคอร์เนล Linuxในขณะนั้น การศึกษาสรุปว่า 40% ของปัญหาจะไม่เกิดขึ้นเลยในไมโครเคอร์เนลที่ได้รับการตรวจสอบอย่างเป็นทางการ และมีเพียง 4% ของปัญหาเท่านั้นที่จะยังคงไม่ได้รับการแก้ไขอย่างสมบูรณ์ในระบบดังกล่าว^{[ 35 ]}

งานวิจัยล่าสุดเกี่ยวกับไมโครเคอร์เนลมุ่งเน้นไปที่ข้อกำหนดอย่างเป็นทางการของ API เคอร์เนล และการพิสูจน์อย่างเป็นทางการของคุณสมบัติด้านความปลอดภัยและความถูกต้องในการใช้งานของ API ตัวอย่างแรกคือการพิสูจน์ทางคณิตศาสตร์ของกลไกการกักขังใน EROS โดยอิงจากแบบจำลองที่ง่ายขึ้นของ API ของ EROS ^{[ 36 ]}เมื่อไม่นานมานี้ (ในปี 2007) ได้มีการดำเนินการพิสูจน์ที่ตรวจสอบด้วยเครื่องจักรอย่างครอบคลุมเกี่ยวกับคุณสมบัติของแบบจำลองการป้องกันของseL4ซึ่งเป็นเวอร์ชันของ L4 ^{[ 37 ]}

^{สิ่ง นี้}นำไปสู่สิ่งที่เรียกว่าไมโครเคอร์เนลรุ่นที่สาม [ ^{38 ]}ซึ่งมีลักษณะเฉพาะคือ API ที่เน้นความปลอดภัยโดยมีการควบคุมการเข้าถึงทรัพยากรด้วยความสามารถการจำลองเสมือนเป็นประเด็นสำคัญอันดับแรก แนวทางใหม่ในการจัดการทรัพยากรเคอร์เนล^{[ 39 ]}และเป้าหมายการออกแบบที่เหมาะสมสำหรับการวิเคราะห์อย่างเป็นทางการนอกเหนือจากเป้าหมายปกติของประสิทธิภาพสูง ตัวอย่างเช่นCoyotos , seL4 , Nova ^{[ 40 ] [ 41 ]} Redoxและ Fiasco.OC ^{[ 40 ] [ 42 ]}

ในกรณีของ seL4 การตรวจสอบอย่างเป็นทางการที่สมบูรณ์ของการใช้งานได้รับการบรรลุผลแล้ว^{[ 38 ]}กล่าวคือ การพิสูจน์ทางคณิตศาสตร์ว่าการใช้งานเคอร์เนลสอดคล้องกับข้อกำหนดอย่างเป็นทางการ ซึ่งให้การรับประกันว่าคุณสมบัติที่พิสูจน์เกี่ยวกับ API นั้นเป็นจริงสำหรับเคอร์เนลจริง ซึ่งเป็นระดับความมั่นใจที่เหนือกว่า CC EAL7 ด้วยซ้ำ ตามมาด้วยการพิสูจน์คุณสมบัติการบังคับใช้ความปลอดภัยของ API และการพิสูจน์ที่แสดงให้เห็นว่ารหัสไบนารีที่สามารถเรียกใช้งานได้นั้นเป็นการแปลที่ถูกต้องของการใช้งาน C โดยนำคอมไพเลอร์ออกจาก TCB เมื่อรวมกันแล้ว การพิสูจน์เหล่านี้สร้างการพิสูจน์แบบครบวงจรของคุณสมบัติความปลอดภัยของเคอร์เนล^{[ 43 ]}

ตัวอย่างของไมโครเคอร์เนล ได้แก่:

• อามิกาโอเอส
• อะมีบา โอเอส
• แบล็กเบอร์รี่คิวเอ็นเอ็กซ์
• จีโนด
• HarmonyOS ( HarmonyOS 5 )
• LiteOS (เลิกผลิตแล้ว)
• เฮเลนโอเอส
• Horizon ( ซอฟต์แวร์ระบบ Nintendo Switch )
• ตระกูลไมโครเคอร์เนล L4
• แมช
• Mac OS 7ถึงMac OS 9 ( Mac OS nanokernel )
• มินิกซ์ (ถูกทิ้งร้าง)
• มิโดริ (เลิกผลิตแล้ว)
• Phantom OS
• ระบบปฏิบัติการคิวบ์
• รีดอกซ์
• ซิมเบียน (เลิกผลิตแล้ว)
• ซิมบโอเอส
• เธรดเอ็กซ์
• เพทาย

ในอดีต คำว่านาโนเคอร์เนลหรือพิโคเคอร์เนลหมายถึง:

• เคอร์เนลที่มีปริมาณโค้ดเคอร์เนลทั้งหมดน้อยมาก กล่าวคือ โค้ดที่ทำงานในโหมดพิเศษของฮาร์ดแวร์ คำว่าpicokernelบางครั้งถูกใช้เพื่อเน้นย้ำถึงขนาดที่เล็กยิ่งขึ้น คำว่าnanokernelถูกบัญญัติขึ้นโดย Jonathan S. Shapiro ในบทความเรื่องThe KeyKOS NanoKernel Architectureเป็นการ ตอบโต้ แบบเสียดสีต่อMachซึ่งอ้างว่าเป็น microkernel ในขณะที่ Shapiro มองว่ามันเป็นระบบแบบรวมศูนย์ ไม่มีโครงสร้าง และช้ากว่าระบบที่มันพยายามจะแทนที่ การนำคำนี้ไปใช้ซ้ำและการตอบโต้ในภายหลัง รวมถึงการบัญญัติคำว่า picokernel แสดงให้เห็นว่าประเด็นสำคัญนั้นถูกมองข้ามไป ทั้งnanokernelและpicokernelจึงมีความหมายเหมือนกับคำว่า microkernel ในเวลาต่อมา
• ชั้นการจำลองเสมือนที่อยู่ใต้ระบบปฏิบัติการ ซึ่งเรียกอย่างถูกต้องว่าไฮเปอร์ไวเซอร์
• เลเยอร์นามธรรมฮาร์ดแวร์ที่ประกอบเป็นส่วนระดับต่ำสุดของเคอร์เนล บางครั้งใช้เพื่อมอบ ฟังก์ชันการทำงาน แบบเรียลไทม์ให้กับระบบปฏิบัติการทั่วไป เช่น Adeos ^{[ 44 ]}

นอกจากนี้ยังมีอย่างน้อยหนึ่งกรณีที่คำว่านาโนเคอร์เนลไม่ได้หมายถึงเคอร์เนลขนาดเล็ก แต่หมายถึงเคอร์เนลที่รองรับความละเอียดของนาฬิการะดับนาโนวินาที^{[ 45 ]}

• โมดูลเคอร์เนลที่โหลดได้
• ไมโครเซอร์วิส
• การโต้วาทีระหว่าง Tanenbaum และ Torvalds
• ยูนิเคอร์เนล
• หลายสภาพแวดล้อมแบบเรียลไทม์

• บทความทางวิทยาศาสตร์เกี่ยวกับไมโครเคอร์เนล (บนCiteSeerX ) รวมถึง:
  • ฮิลเดแบรนด์, แดน (1992). "ภาพรวมทางสถาปัตยกรรมของ QNX". รายงานการประชุมเชิงปฏิบัติการเกี่ยวกับไมโครเคอร์เนลและสถาปัตยกรรมเคอร์เนลอื่นๆหน้า  113–126 . CiteSeerX  10.1.1.459.4481 . ISBN 1-880446-42-1.– เอกสารอ้างอิงพื้นฐานของ QNX
  • Tanenbaum, A.; Herder, J.; Bos, H. (พฤษภาคม 2549). "เราสามารถทำให้ระบบปฏิบัติการมีความน่าเชื่อถือและปลอดภัยได้หรือไม่?" . Computer . 39 (5): 44– 51. Bibcode : 2006Compr..39e..44T . doi : 10.1109/MC.2006.156 . S2CID  99779 . เก็บถาวรจากต้นฉบับเมื่อวันที่ 21 มิถุนายน 2560 . สืบค้นเมื่อ3 เมษายน 2563 .- ข้อมูลอ้างอิงพื้นฐานที่เชื่อถือได้
  • Black, DL; Golub, DB; Julin, DP; Rashid, RF; Draves, RP; Dean, RW; Forin, A.; Barrera, J.; Tokuda, H.; Malan, G.; Bohman, D. (มีนาคม 1992). "สถาปัตยกรรมระบบปฏิบัติการไมโครเคอร์เนลและ Mach". วารสารการประมวลผลข้อมูล 14 ( 4).– ค่าอ้างอิงพื้นฐานของ Mach
• * วาร์โฮล, ปีเตอร์ ดี. (มกราคม 1994). "Small Kernels Hit It Big" . ไบต์ . เก็บถาวรจากต้นฉบับเมื่อวันที่ 7 มีนาคม 2006 . สืบค้นเมื่อ20 กันยายน 2017 .การประเมินสถานะปัจจุบันและอนาคตของระบบปฏิบัติการที่ใช้ไมโครเคอร์เนล ณ เดือนมกราคม พ.ศ. 2537
• หน้า MicroKernelจากPortland Pattern Repository
• การโต้วาทีระหว่าง ทาเนนบอมและทอร์วัลด์ส
  • การโต้วาทีระหว่างทาเนนบอมและทอร์วัลด์ส, 29 มกราคม 1992
  • Tanenbaum, AS " เราสามารถทำให้ระบบปฏิบัติการมีความน่าเชื่อถือและปลอดภัยได้หรือไม่? "
  • ทอร์วัลด์ส, แอล. ไลนัส ทอร์วัลด์ส พูดถึงไมโครเคอร์เนลอีกครั้ง, 9 พฤษภาคม 2549
  • Shapiro, J. " การหักล้างความเชื่อล่าสุดของ Linus "
  • Tanenbaum, AS " การถกเถียงระหว่าง Tanenbaum และ Torvalds: ตอนที่ 2 "