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

Linux API ประกอบด้วย Kernel–User Space API ซึ่งอนุญาตให้โค้ดในพื้นที่ผู้ใช้เข้าถึงทรัพยากรระบบและบริการของเคอร์เนล Linux ^{[ 3 ]}ประกอบด้วยอินเทอร์เฟซการเรียกใช้ระบบของเคอร์เนล Linux และซับรูทีนในไลบรารีมาตรฐาน Cจุดมุ่งหมายของการพัฒนา Linux API คือการจัดหาคุณสมบัติที่ใช้งานได้ของข้อกำหนดที่กำหนดไว้ในPOSIXในลักษณะที่เข้ากันได้ แข็งแกร่ง และมีประสิทธิภาพอย่างเหมาะสม และเพื่อจัดหาคุณสมบัติที่มีประโยชน์เพิ่มเติมที่ไม่ได้กำหนดไว้ใน POSIX เช่นเดียวกับ Kernel–User Space API ของระบบอื่นๆ ที่ใช้ POSIX API ซึ่งมีคุณสมบัติเพิ่มเติมที่ไม่ได้กำหนดไว้ใน POSIX เช่นกัน

API ของ Linux ได้รับการรักษาเสถียรภาพมาหลายทศวรรษโดยนโยบายที่ไม่นำการเปลี่ยนแปลงที่ก่อให้เกิดปัญหามาใช้ ความเสถียรนี้รับประกันความสามารถในการพกพาของซอร์สโค้ด[ ^{4 ] ใน}ขณะเดียวกัน นักพัฒนาเคอร์เนลของ Linux ก็มีความระมัดระวังและพิถีพิถันในการนำการเรียกใช้ระบบใหม่มาใช้มาโดยตลอด

ซอฟต์แวร์โอเพนซอร์สฟรีจำนวนมากเขียนขึ้นสำหรับ POSIX API เนื่องจากมีการพัฒนาจำนวนมากในเคอร์เนล Linux เมื่อเทียบกับเคอร์เนลและไลบรารีมาตรฐาน C ที่สอดคล้องกับ POSIX อื่นๆ เคอร์เนล Linux และ API ของมันจึงได้รับการเสริมด้วยคุณสมบัติเพิ่มเติม การเขียนโปรแกรมสำหรับ Linux API แบบเต็มรูปแบบ แทนที่จะใช้เพียง POSIX API อาจให้ข้อดีในกรณีที่ฟีเจอร์เพิ่มเติมเหล่านั้นมีประโยชน์ ตัวอย่างที่รู้จักกันดีในปัจจุบัน ได้แก่udev , systemdและWeston ^{[ 5} ] บุคคลเช่นLennart Poettering สนับสนุนอย่างเปิดเผยให้เลือก ^ใช้ Linux API มากกว่า POSIX API ในกรณีที่ให้ข้อดี^{[ 6 ]}

ในงาน FOSDEM 2016 Michael Kerriskได้อธิบายถึงปัญหาบางประการที่รับรู้ได้เกี่ยวกับ API พื้นที่ผู้ใช้ของเคอร์เนล Linux โดยระบุว่ามีข้อผิดพลาดในการออกแบบหลายประการ ได้แก่ ไม่สามารถขยายได้ บำรุงรักษาไม่ได้ ซับซ้อนเกินไป มีวัตถุประสงค์จำกัด ละเมิดมาตรฐาน และไม่สอดคล้องกัน ข้อผิดพลาดส่วนใหญ่ไม่สามารถแก้ไขได้ เพราะการแก้ไขจะทำให้ ABI ที่เคอร์เนลนำเสนอต่อพื้นที่ผู้ใช้เสียหาย^{[ 7 ]}

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

ประเด็นปัญหาต่างๆ เกี่ยวกับการจัดระเบียบการเรียกใช้ระบบเคอร์เนล Linux กำลังถูกนำมาพูดคุยกันในวงกว้าง ประเด็นปัญหาเหล่านี้ได้รับการชี้ให้เห็นโดย Andy Lutomirski, Michael Kerriskและคนอื่นๆ^{[ 8 ] [ 9 ] [ 10 ] [ 11 ]}

ไลบรารีมาตรฐานภาษา Cสำหรับลินุกซ์ประกอบด้วยส่วนห่อหุ้มรอบการเรียกใช้ระบบของเคอร์เนลลินุกซ์ การรวมกันของอินเทอร์เฟซการเรียกใช้ระบบของเคอร์เนลลินุกซ์และไลบรารีมาตรฐานภาษา C คือสิ่งที่สร้าง API ของลินุกซ์ การใช้งานไลบรารีมาตรฐานภาษา C ที่ได้รับความนิยมบางส่วน ได้แก่

• glibc
• ยูซีบีแอลซี
• klibc
• นิวลิบ
• มัสล์
• ไดเอทลิบซี
• ลิบบิโอนิกและลิบไฮบริส

แม้ว่าสถานการณ์จะเปลี่ยนแปลงไป แต่ในบรรดาตัวเลือกเหล่านี้ glibc ยังคงเป็นการใช้งานที่ได้รับความนิยมมากที่สุด จนถึงขั้นที่หลายคนถือว่าเป็นค่าเริ่มต้นและมีความหมายเทียบเท่ากับ libc

เช่นเดียวกับ ระบบ ที่คล้าย Unix อื่นๆ เคอร์เนลของ Linux มีความสามารถเพิ่มเติมที่ไม่เป็นส่วนหนึ่งของ POSIX:

• ระบบย่อย cgroupsระบบจะเรียกมันว่าแนะนำและ libcgroup ^{[ 1 ]}
• การเรียกใช้ระบบของDirect Rendering Managerโดยเฉพาะอย่างยิ่ง ioctl ที่เป็นส่วนตัวของไดรเวอร์สำหรับการส่งคำสั่งนั้นไม่ได้ เป็น ส่วนหนึ่งของข้อกำหนด POSIX
• สถาปัตยกรรมเสียงขั้นสูงของ Linux สามารถกำหนดการเรียกใช้ระบบ ซึ่งไม่ได้เป็นส่วนหนึ่งของข้อกำหนด POSIX
• การเรียกใช้ระบบfutex(mutex ผู้ใช้แบบเร็ว) , epoll, splice, dnotify, fanotifyและinotifyเป็นฟังก์ชันเฉพาะของเคอร์เนล Linux มาจนถึงปัจจุบัน
• การเรียกใช้ระบบgetrandomได้รับการแนะนำในเวอร์ชัน 3.17 ของเคอร์เนล Linux หลัก^{[ 12 ]}
• memfdได้รับการเสนอโดยนักพัฒนาkdbus ^{[ 13 ]}
  • memfd_createถูกรวมเข้ากับเคอร์เนลหลักของ Linux ในเวอร์ชันเคอร์เนล 3.17
• readaheadเริ่มต้นการ "อ่านล่วงหน้า" ไฟล์ลงในแคชของเพจ

DRM มีความสำคัญอย่างยิ่งต่อการพัฒนาและการใช้งาน ไดรเวอร์อุปกรณ์กราฟิกแบบโอเพนซอร์สที่มีประสิทธิภาพและชัดเจนซึ่งหากไม่มีไดรเวอร์เหล่านี้ การเร่งความเร็วการเรนเดอร์จะไม่สามารถใช้งานได้เลย จะมีเพียงไดรเวอร์ 2 มิติเท่านั้นที่ใช้งานได้ในX.Org Server DRM ได้รับการพัฒนาสำหรับ Linux และต่อมาได้ถูกพอร์ตไปยังระบบปฏิบัติการอื่น ๆ ด้วย^{[ 14 ]}

• libdrm (สำหรับDirect Rendering Manager )
• libnl (ชุดไลบรารี libnl เป็นชุดไลบรารีที่ให้บริการ API สำหรับอินเทอร์เฟซเคอร์เนล Linux ที่ใช้โปรโตคอล netlink)
• libevdev (สำหรับevdev )
• libasound ( สถาปัตยกรรมเสียงขั้นสูงของลินุกซ์ )

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

ต้องมีการกำหนด ABI สำหรับชุดคำสั่งทุกชุด เช่นx86 , x86-64 , MIPS , ARMv7-A (32 บิต), ARMv8-A (64 บิต) เป็นต้น พร้อมทั้งระบุลำดับไบต์ (endianness ) ด้วย หากชุดคำสั่งนั้นรองรับทั้งสองอย่าง

ควรสามารถคอมไพล์ซอฟต์แวร์ด้วยคอมไพเลอร์ต่างๆ โดยอ้างอิงจากคำจำกัดความที่ระบุไว้ใน ABI และให้ได้ความเข้ากันได้ในระดับไบนารีอย่างสมบูรณ์ คอมไพเลอร์ที่เป็นซอฟต์แวร์โอเพนซอร์สและใช้งานได้ฟรีเช่นGNU Compiler Collection , LLVM / Clangเป็นต้น

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

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

เนื่องจากไม่มี API ในเคอร์เนลที่เสถียร จึงไม่มี ABI ในเคอร์เนลที่เสถียร^{[ 16 ]}

ในหลายกรณี API ของ Linux ถือว่าอยู่ในระดับต่ำเกินไป ดังนั้นจึงต้องใช้ API ที่มีระดับนามธรรมสูงกว่า โดยต้องนำ API ระดับสูงมาพัฒนาต่อยอดจาก API ระดับต่ำ ตัวอย่างเช่น:

• การนำ ข้อกำหนด OpenGLและVulkan มาใช้ ในไดรเวอร์กราฟิก Linux ที่เป็นกรรมสิทธิ์ และการใช้งานแบบโอเพนซอร์สและฟรีในMesa
• การนำข้อกำหนดOpenAL ไปใช้งาน
• เลเยอร์ DirectMedia แบบง่าย : API นามธรรมสำหรับการรับข้อมูล/เสียง/ฯลฯ ที่ใช้งานได้กับระบบปฏิบัติการหลายระบบ
• คลังมัลติมีเดียที่ใช้งานง่ายและรวดเร็ว : เหมือนด้านบน

• ตัวระบุไฟล์  – ตัวระบุทรัพยากรระบบในระบบปฏิบัติการ
• Hybris (ซอฟต์แวร์)  – เลเยอร์ความเข้ากันได้เพื่อเรียกใช้ไดรเวอร์ Android บนระบบ Linux ที่ใช้ glibc หรือ muslหน้าเว็บที่แสดงคำอธิบายสั้น ๆ ของเป้าหมายการเปลี่ยนเส้นทาง
• อินเทอร์เฟซการเขียนโปรแกรมลินุกซ์  – หนังสือโดย ไมเคิล เคอร์ริสก์
• netlink  – อินเทอร์เฟซเคอร์เนลของลินุกซ์สำหรับการสื่อสารระหว่างกระบวนการต่างๆ
• เซมาฟอร์ (การเขียนโปรแกรม)  – ตัวแปรที่ใช้ในระบบแบบขนาน
• การเรียกใช้ระบบ (System Call)  – วิธีที่โปรแกรมสามารถเข้าถึงบริการของเคอร์เนลได้
• Windows API  – ชุดอินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชันหลักของ Microsoft บนระบบปฏิบัติการ Windows
• windows.h  – ไฟล์เฮดเดอร์ภาษาซีสำหรับการเข้าถึง Windows API
• Wine (ซอฟต์แวร์)  – ซอฟต์แวร์ที่ใช้งานร่วมกับ Windows ได้

• Linux Kernel API 5.0 , Memory Management APIs 5.0 ( รูปแบบ Sphinx ใหม่ )
• API ของเคอร์เนล Linux เวอร์ชัน 2.6.20และ4.12 (ในรูปแบบ htmldocs ที่เลิกใช้แล้ว)
• การตรวจสอบการเปลี่ยนแปลง API/ABI สำหรับ Linux
• หนังสือThe Linux Programming Interface กล่าวถึงการเปลี่ยนแปลง ของ Linux และglibc APIนับตั้งแต่หนังสือ The Linux Programming Interfaceวางจำหน่ายในปี 2010
• แผนผังเคอร์เนล Linux แบบโต้ตอบพร้อมฟังก์ชัน API หลักและโครงสร้างเวอร์ชันPDF
• หนังสือ "Linux Device Drivers"โดย Jonathan Corbet, Greg Kroah-Hartman และ Alessandro Rubini ฉบับพิมพ์ครั้งที่ 3
• คำอธิบายเกี่ยวกับ Linked List ในเคอร์เนล Linux ( เก็บถาวรเมื่อ 25 กันยายน 2009 ที่Wayback Machine)