리눅스 커널 인터페이스

Linux kernel interfaces
Linux API, Linux ABI 및 커널 내 API 및 ABI

리눅스 커널은 사용자 공간 및 커널 모드 코드에 다양한 용도로 사용되며 설계에 따라 다양한 속성을 갖는 여러 인터페이스를 제공합니다. 리눅스 커널에는 두 가지 종류의 API(Application Programming Interface)가 있습니다.

  1. "커널-사용자 공간" API; 및
  2. "커널 내부" API.

리눅스 API

리눅스 API는 리눅스 커널의 시스템 호출 인터페이스, GNU C 라이브러리(GNU 기준), libcgroup, libdrm, libalsa 및 libevdev(freedesktop.org 기준)로 구성됩니다.
리눅스 API 대 POSIX API

리눅스 API에는 커널-사용자 공간 API가 포함되어 있어 사용자 공간의 코드가 리눅스 커널의 시스템 리소스 및 서비스에 액세스할 수 있습니다.[3] 리눅스 커널의 시스템 호출 인터페이스와 C 표준 라이브러리의 서브루틴으로 구성되어 있습니다. 리눅스 API 개발의 초점은 POSIX에 정의된 사양의 사용 가능한 기능을 합리적으로 호환되고 강력하며 성능이 뛰어난 방식으로 제공하고 POSIX에 정의되지 않은 추가적인 유용한 기능을 제공하는 것이었습니다. POSIX API를 구현하는 다른 시스템의 커널-사용자 공간 API도 POSIX에 정의되지 않은 추가 기능을 제공하는 것처럼 말입니다.

선택적으로 리눅스 API는 수십 년 동안 중단 변경을 도입하지 않는 정책을 통해 안정성을 유지해 왔습니다. 이러한 안정성은 소스 코드의 휴대성을 보장합니다.[4] 동시에 리눅스 커널 개발자들은 역사적으로 새로운 시스템 호출을 도입하는 것에 대해 보수적이고 세심했습니다.[citation needed]

POSIX API를 위해 사용 가능한 많은 무료 및 오픈 소스 소프트웨어가 작성되었습니다. 다른 POSIX 호환 커널과 C 표준 라이브러리의 조합에 비해 훨씬 더 많은 개발이 리눅스 커널로 유입되기 [citation needed]때문에 리눅스 커널과 그 API는 추가 기능으로 보강되었습니다. POSIX API뿐만 아니라 전체 Linux API를 위한 프로그래밍은 이러한 추가 기능이 유용한 경우에 이점을 제공할 수 있습니다. 현재 잘 알려진 예로는 udev, systemd 및 Weston이 있습니다.[5] Lennart Poettering과 같은 사람들은 POSIX API보다 Linux API를 선호한다고 공개적으로 주장합니다. 여기서 이점이 제공됩니다.[6]

FOSDEM 2016에서 마이클 커리스크(Michael Kerrisk)는 리눅스 커널의 사용자 공간 API에 대한 인식된 문제 중 일부를 설명하면서 확장 불가능하고, 유지할 수 없으며, 지나치게 복잡하며, 제한된 목적, 표준을 위반하고, 일관성이 없음으로 인해 여러 설계 오류가 포함되어 있다고 설명했습니다. 이러한 실수의 대부분은 커널이 사용자 공간에 제공하는 ABI를 깨뜨릴 수 있기 때문에 수정할 수 없습니다.[7]

리눅스 커널의 시스템 호출 인터페이스

커널의 시스템 호출 인터페이스는 커널에서 구현되고 사용 가능한 모든 시스템 호출 집합입니다. 리눅스 커널에서 DRM(Direct Rendering Manager)과 같은 다양한 하위 시스템은 자체 시스템 호출을 정의하며, 이는 모두 시스템 호출 인터페이스의 일부입니다.

리눅스 커널 시스템 호출의 구성에 대한 다양한 문제들이 공개적으로 논의되고 있습니다. 앤디 루토미르스키(Andy Lutomirski), 마이클 케리스크(Michael Kerrisk) 등이 문제를 지적했습니다.[8][9][10][11]

C 표준 라이브러리

GNU C 라이브러리는 리눅스 커널 시스템 호출 인터페이스에 대한 래퍼입니다.

리눅스용 C 표준 라이브러리에는 리눅스 커널의 시스템 호출에 대한 랩퍼가 포함되어 있습니다. 리눅스 커널 시스템 호출 인터페이스와 C 표준 라이브러리의 조합이 리눅스 API를 구축합니다. C 표준 라이브러리의 몇 가지 인기 있는 구현은 다음과 같습니다.

POSIX에 대한 추가 사항

다른 유닉스 계열 시스템과 마찬가지로 리눅스 커널의 추가 기능은 POSIX에 속하지 않습니다.

DRM은 렌더링 가속을 전혀 사용할 수 없고 2D 드라이버만 X에서 사용할 수 있는 잘 정의되고 성능이 뛰어난 자유 및 오픈 소스 그래픽 장치 드라이버의 개발 및 구현에 가장 중요한 역할을 해왔습니다.Org Server. DRM은 리눅스용으로 개발되었으며, 이후 다른 운영 체제에도 이식되었습니다.[14]

추가 라이브러리

리눅스 ABI

리눅스 API 및 리눅스 ABI
주요 문서: x32 ABI 및 리눅스 표준 기반

리눅스 ABI라는 용어는 커널-사용자 공간 ABI를 말합니다. 애플리케이션 바이너리 인터페이스는 컴파일된 바이너리를 머신 코드로 나타냅니다. 따라서 이러한 ABI는 명령어 세트에 속합니다. 유용한 ABI를 정의하고 안정성을 유지하는 것은 리눅스 커널 개발자들이나 GNU C 라이브러리 개발자들의 책임이 덜하며, 그러한 단일 리눅스 ABI에 대해서만 바이너리로서 그들의 독점 소프트웨어를 판매하고 지원하기를 원하는 리눅스 배포판과 독립 소프트웨어 공급업체(ISV)들을 위한 더 많은 작업입니다. 여러 개의 리눅스 ABI를 지원하는 것과는 반대입니다.

ABI는 x86, x86-64, MIPS, ARMv7-A(32-Bit), ARMv8-A(64-Bit) 등과 같은 모든 명령어 세트에 대해 엔디안을 지원하는 경우 정의되어야 합니다.

ABI에 명시된 정의에 따라 서로 다른 컴파일러로 소프트웨어를 컴파일하고 완전한 바이너리 호환성을 달성할 수 있어야 합니다. 자유 및 오픈 소스 소프트웨어인 컴파일러는 예를 들어 다음과 같습니다. GNU 컴파일러 모음, LLVM/Clang.

커널 내 API

많은 커널 내부 API가 존재하여 커널 서브시스템이 서로 인터페이스할 수 있습니다. 이것들은 상당히 안정적으로 유지되고 있지만, 안정성에 대한 보장은 없습니다. 커널-내부 API는 새로운 연구나 통찰력에 의해 그러한 필요성을 나타낼 때 변경될 수 있습니다. 모든 필요한 수정 및 테스트는 저자가 수행해야 합니다.

리눅스 커널은 단일 커널이므로 장치 드라이버는 커널 구성 요소입니다. 기업이 메인 커널 트리 외부에서 디바이스 드라이버를 유지하는 부담을 완화하기 위해 디바이스 드라이버에 대한 안정적인 API가 지속적으로 요청되었습니다. 리눅스 커널 개발자들은 디바이스 드라이버에 대한 안정적인 인커널 API 보장을 거듭 거부했습니다. 이를 보장하는 것은 과거 리눅스 커널의 개발을 흔들었을 것이고, 미래에도 그럴 것이며, 자유 소프트웨어와 오픈 소스 소프트웨어의 특성상 필요하지 않습니다. 선택적으로 리눅스 커널에는 안정적인 인커널 API가 없습니다.[15]

In-kernel ABIs

안정적인 인커널 API가 없으므로 안정적인 인커널 ABI는 존재할 수 없습니다.[16]

추상화 API

OpenGL은 실제로 각 벤더에 대해 특별히 프로그래밍할 필요 없이 여러 벤더의 다양한 GPU를 사용할 수 있는 추상화 API입니다.
그러나 OpenGL-사양의 구현은 실행 중인 운영 체제의 맥락에서 CPU에서 실행됩니다. Vulkan의 설계 목표 중 하나는 "그래픽 드라이버", 즉 그래픽 API의 구현을 줄이는 것이었습니다.

많은 사용 사례에서 Linux API는 너무 낮은 수준으로 간주되므로 추상화 수준이 높은 API를 사용해야 합니다. 하위 수준 API 위에 상위 수준 API를 구현해야 합니다. 예:

참고 항목

  • Michael Kerrisk의 리눅스 프로그래밍 인터페이스
  • 세마포어(프로그래밍)
  • system call – 프로그램이 커널로부터 서비스를 요청할 수 있도록 지원하는 기능입니다.
    • eventfd ()
    • 넷링크 – ioctl의 후속 제품으로 설계된 커널과 사용자 공간 프로세스 사이의 IPC에 사용되는 소켓 제품군; 넷링크는 리눅스 커널 1.3 개발 중에 여러 커널 및 사용자 공간 양방향 통신 링크를 제공하기 위한 캐릭터 드라이버 인터페이스로 앨런 콕스에 의해 추가되었습니다. 그런 다음 Alexey Kuznetsov는 Linux 커널 2.1 개발 중에 확장하여 새로운 고급 라우팅 인프라에 유연하고 확장 가능한 메시징 인터페이스를 제공했습니다. 그 이후로 Netlink 소켓은 커널 서브시스템이 리눅스의 사용자 공간 애플리케이션에 제공하는 주요 인터페이스 중 하나가 되었습니다. 현대의 WNIC 드라이버는 사용자 공간과 통신하기 위해 이를 사용합니다.
  • Windows API – Microsoft Windows 운영 체제에서 사용할 수 있는 다양한 API에 대한 문서
  • 와인 – Microsoft Windows용으로 작성된 Linux와 프로그램 간의 호환성 계층
  • libhybris – Android용으로 작성된 Linux와 프로그램 간의 호환성 계층

참고문헌

  1. ^ a b "ControlGroupInterface". freedesktop.org.
  2. ^ "libevdev". freedesktop.org.
  3. ^ Alessandro Rubini (2006-11-02). "Kernel System Calls". linux.it. Retrieved 2014-11-11.
  4. ^ Linus Torvalds (2012-12-23). "Re: [Regression w/ patch] Media commit causes user space to misbahave (was: Re: Linux 3.8-rc1)". Linux kernel mailing list. Retrieved 2014-08-26. 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. 2011-03-02.
  6. ^ "Interview: Lennart Poettering - Lennart Poettering will give a talk about "Systemd: beyond init" at FOSDEM 2011". fosdem.org. 2011. Retrieved 2014-06-16. 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 (2016-01-31). "How to design a Linux kernel API". Retrieved 2016-02-04.
  8. ^ "System Call Organization".
  9. ^ "Making a universal list of syscalls?". LKML. 2014-02-27.
  10. ^ "Flags as a system call API design pattern". LWN.net. 2014-02-12.
  11. ^ "On vsyscalls and the vDSO". LWN.net. 2011-06-08.
  12. ^ "[PATCH, RFC] random: introduce getrandom(2) system call". LKML. 2014-07-17.
  13. ^ "memfd.c". GitHub. Archived from the original on 2014-04-22.
  14. ^ "NetBSD 7.0 Will Finally Have DRM/KMS Drivers". Phoronix. 2014-03-19.
  15. ^ "The Linux Kernel Driver Interface".
  16. ^ "Analysis of ABI changes in the Linux kernel". Andrey Ponomarenko's ABI laboratory. 2016-03-15.

외부 링크