Bước tới nội dung

Giao diện nhân Linux

Bách khoa toàn thư mở Wikipedia
Linux API, Linux ABI, API và ABI trong nhân

Nhân Linux cung cấp một số giao diện cho các ứng dụng ở không gian người dùng sử dụng cho các mục đích khác nhau và có các thuộc tính khác nhau tùy theo thiết kế. Có hai loại giao diện lập trình ứng dụng (API) trong nhân Linux, không nên nhầm lẫn giữa: API "hạt nhân – không gian người dùng" và API "nội bộ hạt nhân".

API Linux

[sửa | sửa mã nguồn]
API Linux được cấu thành từ Giao diện cuộc gọi hệ thống của nhân Linux, Thư viện GNU C (bởi GNU), libcgroup,[1] libdrm, libalsa và libevdev [2] (bởi freedesktop.org).
API Linux so với API POSIX

API Linux là API hạt nhân – người sử dụng không gian, cho phép các chương trình trong không gian người dùng có thể truy cập hệ thống tài nguyên và các dịch vụ của hạt nhân Linux.[3] Nó được cấu thành từ Giao diện cuộc gọi hệ thống của nhân Linux và các chương trình con trong Thư viện GNU C (glibc). Trọng tâm của sự phát triển API Linux là cung cấp các tính năng có thể sử dụng của các thông số kỹ thuật được xác định trong POSIX theo cách tương thích hợp lý, mạnh mẽ và hiệu quả và cung cấp các tính năng hữu ích bổ sung không có trong POSIX, giống như các API hạt nhân– không gian người dùng của các hệ thống khác đang triển khai trên API POSIX cũng cung cấp các tính năng bổ sung không có trong POSIX.

API Linux, theo lựa chọn, đã được giữ ổn định trong nhiều thập kỷ và không bao giờ bị phá vỡ;   sự ổn định này đảm bảo tính di động của mã nguồn.[4] Đồng thời, các nhà phát triển nhân Linux trong lịch sử đã bảo thủ và tỉ mỉ trong việc giới thiệu các cuộc gọi hệ thống mới.   Nhiều phần mềm nguồn mở và miễn phí có sẵn được viết cho API POSIX. Do có quá nhiều dòng phát triển vào nhân Linux so với các nhân tương thích với POSIX khác và thư viện chuẩn của C,nhân Linux và API của nó đã được tăng cường với các tính năng bổ sung. Theo như các tính năng bổ sung này cung cấp lợi thế kỹ thuật, lập trình cho API Linux được ưu tiên hơn API-POSIX. Các ví dụ nổi tiếng hiện nay là udev, systemd và Weston.[5] Những người như Lennart Poettering công khai ủng hộ API Linux hơn API POSIX, nơi điều này mang lại lợi thế.[6]

Tại FOSDEM 2016, Michael Kerrisk đã giải thích một số vấn đề được nhận thấy với API không gian người dùng của hạt nhân Linux, mô tả rằng nó chứa nhiều lỗi thiết kế do không thể mở rộng, không thể hiểu được, quá phức tạp, vi phạm các tiêu chuẩn và không nhất quán. Hầu hết các lỗi đó không thể sửa được vì làm như vậy sẽ phá vỡ ABI mà kernel thể hiện cho không gian người dùng.[7]

Giao diện cuộc gọi hệ thống của nhân Linux

[sửa | sửa mã nguồn]

Giao diện cuộc gọi hệ thống là toàn bộ tất cả các cuộc gọi hệ thống được triển khai và có sẵn trong một hạt nhân. Các hệ thống con khác nhau, chẳng hạn như DRM xác định các cuộc gọi hệ thống của riêng chúng và toàn bộ được gọi là Giao diện cuộc gọi hệ thống.

Nhiều vấn đề khác nhau với việc tổ chức các cuộc gọi hệ thống nhân Linux đang được thảo luận công khai. Nhiều vấn đề đã được chỉ ra bởi Andy Lutomirski, Michael Kerrisk và những người khác.[8][9][10][11]

Thư viện chuẩn C

[sửa | sửa mã nguồn]
Thư viện GNU C là một trình bao bọc xung quanh Giao diện cuộc gọi hệ thống nhân Linux.

Thư viện GNU C là một trình bao bọc xung quanh các lệnh gọi hệ thống của nhân Linux; sự kết hợp giữa Giao diện cuộc gọi hệ thống nhân Linux và glibc là thứ xây dựng lên API Linux.

Bổ sung vào POSIX

[sửa | sửa mã nguồn]

Giống như trong các hệ thống tương tự Unix khác, các API bổ sung của nhân Linux không phải là một phần của POSIX:

  • hệ thống con cgroups, hệ thống gọi nó là giới thiệu và libcgroup [1]
  • Các cuộc gọi hệ thống của Trình quản lý kết xuất trực tiếp, đặc biệt là các ioctls riêng cho trình điều khiển để gửi lệnh không phải là một phần của thông số kỹ thuật POSIX.
  • Kiến trúc âm thanh Linux nâng cao có thể đặt các cuộc gọi hệ thống, không phải là một phần của thông số kỹ thuật POSIX
  • Hệ thống gọi futex (mutex không gian người dùng nhanh), epoll, splice, dnotify, fanotify và inotify đã được dành riêng cho kernel Linux tư trước đến nay.
  • Cuộc gọi hệ thống getrandom đã được giới thiệu trong phiên bản 3.17 của dòng chính Linux kernel [12]
  • memfd được đề xuất bởi các nhà phát triển kdbus [13]
    • memfd_create đã được hợp nhất vào dòng chính của nhân Linux trong phiên bản kernel 3.17
  • readahead khởi tạo một tập tin "đọc trước" vào bộ đệm trang

DRM là tối quan trọng cho việc phát triển và triển khai các trình điều khiển thiết bị đồ họa nguồn mở và miễn phí được xác định rõ ràng và hiệu năng mà không có khả năng tăng tốc kết xuất nào khả dụng, hoặc thậm chí tệ hơn, chỉ có các trình điều khiển 2D mới có sẵn trong X.Org Máy chủ. DRM được phát triển cho Linux và từ đó cũng đã được chuyển sang các hệ điều hành khác.[14]

Thư viện khác

[sửa | sửa mã nguồn]
  • libdrm (dành cho Trình quản lý kết xuất trực tiếp)
  • libnl (Bộ libnl là một tập hợp các thư viện cung cấp API cho các giao diện kernel dựa trên giao thức netlink.)
  • libevdev (cho evdev)
  • libasound (Kiến trúc âm thanh Linux nâng cao)
  • ...

Linux ABI

[sửa | sửa mã nguồn]
API Linux và ABI Linux

Thuật ngữ Linux ABI dùng để chỉ một ABI không gian người dùng của kernel. Giao diện nhị phân ứng dụng đề cập đến các thư viện được biên dịch, trong mã máy. Bất kỳ ABI như vậy do đó bị ràng buộc với tập lệnh. Xác định ABI hữu ích và giữ ổn định là trách nhiệm của các nhà phát triển nhân Linux hoặc của các nhà phát triển Thư viện GNU C và nhiệm vụ cho các nhà phân phối Linux và nhà cung cấp phần mềm độc lập (ISV) muốn bán và cung cấp hỗ trợ cho họ phần mềm độc quyền dưới dạng nhị phân chỉ dành cho một ABI Linux duy nhất, trái ngược với việc hỗ trợ nhiều ABI Linux.

Một ABI phải được xác định cho mỗi tập lệnh, chẳng hạn như x86, x86-64, MIPS, ARMv7-A (32-Bit), ARMv8-A (64-Bit), vv với endianness, nếu cả hai được hỗ trợ.

Nó có thể biên dịch phần mềm với các trình biên dịch khác nhau theo các định nghĩa được chỉ định trong ABI và đạt được khả năng tương thích nhị phân đầy đủ. Trình biên dịch là phần mềm miễn phí và nguồn mở, vd Bộ sưu tập trình biên dịch GNU, LLVM / Clang.

Trên thực tế, người dùng cuối không phải tất cả đều quan tâm đến API Linux (hoặc API Windows), mà là ABI.

API nội bộ hạt nhân

[sửa | sửa mã nguồn]

Có rất nhiều API bên trong nhân cho tất cả các hệ thống con để có thể giao tiếp với nhau. Chúng đang được giữ khá ổn định, nhưng không có gì đảm bảo cho sự ổn định. Trong trường hợp nghiên cứu mới hoặc thông tin chi tiết làm cho thay đổi có vẻ thuận lợi, API sẽ được thay đổi, tất cả việc viết lại và kiểm tra cần thiết phải được thực hiện bởi tác giả.

Nhân Linux là một hạt nhân nguyên khối, do đó trình điều khiển thiết bị là các thành phần hạt nhân. Để giảm bớt gánh nặng của các công ty duy trì các trình điều khiển thiết bị (độc quyền) ngoài luồng, các API ổn định cho trình điều khiển thiết bị đã được yêu cầu nhiều lần. Các nhà phát triển nhân Linux đã liên tục phủ nhận việc đảm bảo các API trong kernel ổn định cho trình điều khiển thiết bị. Việc đảm bảo như vậy sẽ cản trở sự phát triển của nhân Linux trong quá khứ và trong tương lai và, do bản chất của phần mềm miễn phí và nguồn mở, là không cần thiết. Ergo, theo lựa chọn, hạt nhân Linux không có API nội bộ hạt nhân ổn định.[15]

ABI nội bộ hạt nhân

[sửa | sửa mã nguồn]

Vì không có API nội bộ hạt nhân ổn định, nên không thể có ABI nội bộ hạt nhân ổn định.[16]

API trừu tượng

[sửa | sửa mã nguồn]
OpenGL thực sự là một API trừu tượng để sử dụng GPU đa dạng của nhiều nhà cung cấp mà không cần phải lập trình cụ thể cho từng nhà cung cấp.
Nhưng việc triển khai đặc tả OpenGL được thực thi trên CPU trong bối cảnh hệ điều hành đang chạy. Một mục tiêu thiết kế của Vulkan là làm cho "trình điều khiển đồ họa", tức là việc triển khai API đồ họa, làm ít hơn.

Đối với một số trường hợp sử dụng, API Linux được coi là API ở mức độ thấp và các API trừu tượng cao hơn được sử dụng. Tất nhiên như vậy vẫn cần phải hoạt động trên các API Linux cấp thấp. Ví dụ:

  • triển khai các thông số kỹ thuật OpenGL và Vulkan trong trình điều khiển đồ họa Linux độc quyền và triển khai nguồn mở và miễn phí trong Mesa
  • triển khai đặc tả OpenAL
  • Lớp DirectMedia đơn giản: API trừu tượng cho đầu vào / âm thanh / vv. có sẵn cho nhiều hệ điều hành
  • Thư viện đa phương tiện đơn giản và nhanh chóng: như trên

Xem thêm

[sửa | sửa mã nguồn]
  • Giao diện lập trình Linux của Michael Kerrisk
  • Semaphore (lập trình)
  • cuộc gọi hệ thống  – là một chức năng để tạo điều kiện cho các chương trình yêu cầu dịch vụ từ kernel
    • eventfd ()
    • [./https://en.wikipedia.org/wiki/Netlink netlink] – họ ổ cắm được sử dụng cho IPC giữa các tiến trình không gian người dùng và nhân, được thiết kế như là sự kế thừa của ioctl; Netlink đã được Alan Cox thêm vào trong quá trình phát triển kernel 1.3 của Linux dưới dạng giao diện trình điều khiển nhân vật để cung cấp nhiều liên kết truyền thông hai chiều và không gian người dùng. Sau đó, Alexey Kuznetsov đã mở rộng nó trong quá trình phát triển nhân Linux 2.1 để cung cấp giao diện nhắn tin linh hoạt và có thể mở rộng cho cơ sở hạ tầng định tuyến tiên tiến mới. Kể từ đó, các ổ cắm Netlink đã trở thành một trong những giao diện chính mà các hệ thống con kernel cung cấp cho các ứng dụng không gian người dùng trong Linux. Trình điều khiển WNIC hiện đại sử dụng nó để giao tiếp với không gian người dùng.
  • API Windows  – bài viết về API khác nhau có sẵn trên hệ điều hành Microsoft Windows
  • [./https://en.wikipedia.org/wiki/Wine_(software) Wine] – một lớp tương thích giữa Linux và các chương trình được viết cho Microsoft Windows
  • libhybris - lớp tương thích giữa Linux và các chương trình được viết cho Android

Tham khảo

[sửa | sửa mã nguồn]
  1. ^ a b “ControlGroupInterface”. freedesktop.org.
  2. ^ “libevdev”. freedesktop.org.
  3. ^ Alessandro Rubini (ngày 2 tháng 11 năm 2006). “Kernel System Calls”. linux.it. Truy cập ngày 11 tháng 11 năm 2014.
  4. ^ Linus Torvalds (ngày 23 tháng 12 năm 2012). “Re: [Regression w/ patch] Media commit causes user space to misbahave (was: Re: Linux 3.8-rc1)”. Linux kernel mailing list. Truy cập ngày 26 tháng 8 năm 2014. If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs.
  5. ^ “Choosing between portability and innovation”. LWN.net. ngày 2 tháng 3 năm 2011.
  6. ^ “Interview: Lennart Poettering - Lennart Poettering will give a talk about "Systemd: beyond init" at FOSDEM 2011”. fosdem.org. 2011. Truy cập ngày 16 tháng 6 năm 2014. In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!
  7. ^ Michael Kerrisk (ngày 31 tháng 1 năm 2016). “How to design a Linux kernel API”. Truy cập ngày 4 tháng 2 năm 2016.
  8. ^ “System Call Organization”.
  9. ^ “Making a universal list of syscalls?”. LKML. ngày 27 tháng 2 năm 2014.
  10. ^ “Flags as a system call API design pattern”. LWN.net. ngày 12 tháng 2 năm 2014.
  11. ^ “On vsyscalls and the vDSO”. LWN.net. ngày 8 tháng 6 năm 2011.
  12. ^ “[PATCH, RFC] random: introduce getrandom(2) system call”. LKML. ngày 17 tháng 7 năm 2014.
  13. ^ “memfd.c”. Bản gốc lưu trữ ngày 22 tháng 4 năm 2014.
  14. ^ “NetBSD 7.0 Will Finally Have DRM/KMS Drivers”. Phoronix. ngày 19 tháng 3 năm 2014.
  15. ^ “The Linux Kernel Driver Interface”.
  16. ^ “Analysis of ABI changes in the Linux kernel”. Andrey Ponomarenko's ABI laboratory. ngày 15 tháng 3 năm 2016.

Liên kết ngoài

[sửa | sửa mã nguồn]
Lấy từ “https://vi.wikipedia.org/w/index.php?title=Giao_diện_nhân_Linux&oldid=71723829”