Linux

Linux 는 컴퓨터의 커널입니다. 커널은 하드웨어를 프로그램들에게 나눠주는 프로그램입니다. 유닉스를 본떠 밑바닥부터 새로 짠 물건입니다.

상세

커널 문서의 README 는 Linux 를 유닉스라는 운영체제의 클론이라고 적습니다. Linus Torvalds 가 밑바닥부터 썼고 네트워크 너머의 느슨하게 얽힌 해커 팀이 거들었다고 적습니다. 지향점도 스스로 밝힙니다. POSIX(Portable Operating System Interface)와 Single UNIX Specification 준수를 향해 간다는 것입니다.

같은 문서는 현대적인 유닉스에 있을 법한 것들을 갖췄다고 적습니다. 진짜 멀티태스킹과 가상 메모리, 제대로 된 메모리 관리 같은 것들입니다. 여기까지가 이 물건이 자기 일이라고 적어둔 범위입니다.

이식이 되는 조건

처음에는 32비트 x86 PC 를 위해 만들어졌습니다. 지금은 Compaq Alpha AXP, SPARC, PowerPC, ARM, IBM S/390, MIPS, AMD x86-64 같은 아키텍처에서도 돕니다.

문서는 페이지 단위 메모리 관리 장치와 GNU C 컴파일러의 포팅만 있으면 대부분의 범용 32비트·64비트 아키텍처에 쉽게 이식된다고 적습니다.

라이선스와 시스템콜 경계

라이선스 규칙 문서는 커널이 GNU General Public License version 2 only, 곧 GPL-2.0 아래에서 제공된다고 적습니다. 여기에 명시적인 시스템콜 예외가 붙습니다.

문서는 시스템콜 인터페이스를 분명한 경계라고 부릅니다. 커널과 통신하려고 그 인터페이스를 쓰는 소프트웨어에는 GPL 요구가 미치지 않습니다. 유저스페이스 API(User-space Application Programming Interface, UAPI) 헤더 파일이 특별한 경우입니다. 이 헤더는 Linux 커널 위에서 도는 실행 파일을 만드는 어떤 소스 파일에도 들어갈 수 있어야 합니다. 그래서 그 예외를 특별한 라이선스 표현으로 문서화한다고 적습니다.

릴리스가 도는 방식

개발 과정 문서는 Linux 커널이 느슨하게 시간에 기반한 롤링 릴리스 모델을 쓴다고 적습니다. 새 메이저 릴리스가 두세 달마다 나옵니다. 릴리스 하나에 대략 13,000개의 체인지셋이 담길 수 있고 수십만 줄이 바뀝니다.

flowchart TD
    A["병합창 열림 · 약 2주"] --> B["창을 닫고 -rc1 릴리스"]
    B --> C["6~10주 · 문제를 고치는 패치만"]
    C --> D["-rc6 ~ -rc9 쯤에서 최종 릴리스"]

주기 첫머리에 병합창이 열립니다. 그때 충분히 안정되었다고 판단되고 개발 공동체가 받아들인 코드가 메인라인 커널로 병합됩니다. 병합창은 두 주쯤 갑니다. 창이 닫히면 Linus Torvalds 가 첫 rc 커널을 냅니다. -rc1 은 새 기능을 병합할 시간이 지났다는 신호입니다. 그 뒤 6주에서 10주 동안은 문제를 고치는 패치만 메인라인에 올려야 합니다. rc 커널은 대략 한 주에 한 번 나옵니다. 보통 -rc6 에서 -rc9 사이에서 커널이 충분히 안정되었다고 보고 최종 릴리스를 냅니다.

포기한 것

커널 안쪽의 안정된 인터페이스

Greg Kroah-Hartman 이 쓴 문서가 이 결정을 정면으로 다룹니다. Linux 에는 바이너리 커널 인터페이스가 없습니다. 안정된 커널 인터페이스도 없습니다. 문서는 왜 그런지를 설명하려고 쓴 글이라고 스스로 밝힙니다.

요약도 문서 안에 있습니다. 당신은 안정된 커널 인터페이스를 원한다고 생각하지만 사실은 원하지 않으며 그 사실조차 모른다는 것입니다. 원하는 것은 안정적으로 도는 드라이버입니다. 그리고 그것은 드라이버가 메인 커널 트리 안에 있을 때만 얻는다고 적습니다.

이유를 셋으로 댑니다. 쓰는 C 컴파일러 판에 따라 커널 자료구조의 정렬이 달라집니다. 함수를 인라인으로 넣느냐 마느냐도 달라질 수 있습니다. 다음으로 Linux 는 여러 프로세서 아키텍처에서 돕니다. 한 아키텍처의 바이너리 드라이버가 다른 아키텍처에서 제대로 돌 방법이 없습니다. 마지막으로 커널 개발은 속도를 늦추는 법 없이 계속됩니다. 개발자들이 현재 인터페이스에서 버그를 찾거나 더 나은 방법을 알아내면 인터페이스를 고칩니다. 그때 함수 이름이 바뀌고 구조체가 커지거나 줄고 인자가 바뀝니다.

대신 얻은 것을 같은 문서가 적습니다. 드라이버가 트리 안에 있으면 커널 인터페이스가 바뀔 때 그 변경을 한 사람이 드라이버를 고쳐 줍니다. 원래 개발자가 거의 손대지 않아도 드라이버가 계속 빌드되고 시간이 지나도 계속 돕니다. 다른 개발자가 기능을 더합니다. 다른 사람이 버그를 찾아 고칩니다. 쓰는 사람이 없는 인터페이스는 지웁니다. 그래야 커널이 가능한 한 작게 유지되고 모든 인터페이스가 시험될 수 있다고 적습니다.

유저스페이스 쪽을 깨는 자유

같은 문서가 경계를 먼저 긋습니다. 방금까지의 이야기는 커널 안쪽 인터페이스입니다. 커널과 유저스페이스 사이의 인터페이스가 아닙니다. 응용 프로그램이 쓰는 쪽은 시스템콜 인터페이스입니다. 문서는 그 인터페이스가 시간이 지나도 매우 안정적이며 깨지지 않을 것이라고 적습니다. 0.9 언저리 커널에서 빌드한 옛 프로그램이 최신 2.6 커널 릴리스에서도 잘 돈다고 덧붙입니다.

ABI(Application Binary Interface) 문서가 그 안정성을 네 단계로 나눕니다. stable/ 디렉터리는 개발자가 안정적이라고 정한 인터페이스를 문서화합니다. 유저스페이스 프로그램은 제한 없이 그 인터페이스를 쓸 수 있습니다. 하위 호환은 최소 2년 동안 보장됩니다. 시스템콜 같은 대부분의 인터페이스는 결코 바뀌지 않고 언제나 있을 것으로 기대된다고 적습니다.

안쪽 인터페이스와 바깥쪽 인터페이스에 서로 다른 규칙이 붙어 있습니다. 안쪽은 마음대로 고치고 바깥쪽은 고치지 않습니다.

stable 트리의 새 기능

stable 릴리스 규칙 문서가 -stable 트리에 무엇을 받고 무엇을 안 받는지 목록으로 적습니다. 수정이나 그에 준하는 것이 이미 Linux 메인라인에 있어야 합니다. 명백히 옳고 시험을 거쳐야 합니다. 문맥을 포함해 100줄을 넘을 수 없습니다. 진짜로 사람을 괴롭히는 버그를 고치거나 장치 ID 를 더하는 것이어야 합니다. 문서가 드는 예는 oops, 멈춤, 데이터 손상, 실제 보안 문제, 하드웨어 특이 동작, 빌드 오류입니다. 다만 빌드 오류라도 CONFIG_BROKEN 으로 표시된 것은 빼라고 적습니다.

안 받는 것도 이름으로 적습니다. "이론적인 경쟁 조건" 같은 "이럴 수도 있다" 류는 안 받습니다. 그 버그를 어떻게 악용할 수 있는지 설명이 같이 오면 예외입니다. 사용자에게 이득이 없는 사소한 수정도 안 받습니다. 철자 고침과 공백 정리가 그 예로 적혀 있습니다.

여기서 포기한 것은 새 기능입니다. 얻은 것은 stable 로 내려온 수정이 전부 메인라인에도 있다는 것입니다. 크기도 100줄이라는 값으로 못 박혀 있습니다.

예시

Android 공통 커널

Android 오픈소스 프로젝트 문서는 Android 공통 커널을 ACK(Android Common Kernel)라고 부릅니다. kernel/common 저장소에서 빌드합니다. 이 저장소는 업스트림 Linux 커널의 상위집합입니다. Android 공동체에 필요한 패치가 더 얹혀 있습니다. 5.10 이상의 ACK 는 GKI(Generic Kernel Image) 커널이라고도 부릅니다. GKI 커널은 하드웨어와 무관한 제네릭 코어 커널 코드와 GKI 모듈을, 하드웨어에 묶인 벤더 모듈로부터 분리할 수 있게 합니다.

무엇을 기반으로 골랐는지가 정의에 적혀 있습니다. ACK 는 LTS(Long Term Supported) 커널의 하류입니다. LTS 커널은 2년에서 6년 동안 지원됩니다. 1년에 한 번 릴리스됩니다. 문서는 그 LTS 커널이 구글의 Android 공통 커널 각각의 기반이라고 적습니다.

쿠버네티스가 붙는 cgroup

커널 문서는 cgroup 을 프로세스를 계층으로 조직하고 시스템 자원을 그 계층을 따라 통제 가능하고 설정 가능한 방식으로 배분하는 메커니즘이라고 정의합니다. cgroup 은 코어와 컨트롤러 두 부분으로 이뤄집니다. 코어는 프로세스를 계층으로 조직하는 일을 맡습니다. 컨트롤러는 특정 종류의 시스템 자원을 계층을 따라 배분하는 일을 맡습니다. cgroup 은 트리를 이룹니다. 시스템의 모든 프로세스가 정확히 하나의 cgroup 에 속합니다. 한 프로세스의 모든 스레드는 같은 cgroup 에 속합니다.

쿠버네티스 문서가 그 위에 앉습니다. kubelet 과 그 아래의 컨테이너 런타임이 cgroup 과 인터페이스해야 Pod 과 컨테이너의 자원 관리를 강제할 수 있다고 적습니다. 컨테이너 워크로드의 CPU(Central Processing Unit)·메모리 요청과 상한이 거기에 들어갑니다. Linux 에는 cgroup v1 과 cgroup v2 두 판이 있다고 덧붙입니다.

경계

Debian 을 깔았으면 Linux 를 깐 것인가. 맞습니다. 다만 Linux 만 깐 것은 아닙니다.

Debian 프로젝트는 자기네가 만든 자유 운영체제를 Debian 이라고 부릅니다. 운영체제를 컴퓨터를 돌게 하는 기본 프로그램과 유틸리티의 묶음이라고 정의합니다. 그 한가운데에 커널이 있습니다. 커널은 컴퓨터에서 가장 근본적인 프로그램이고 기본 살림을 다 하며 다른 프로그램을 띄워 준다고 적습니다. 문서는 탑에 비유합니다. 맨 아래가 커널입니다. 그 위에 기본 도구들이 옵니다. 맨 위에 Debian 이 있습니다.

판정 근거는 같은 문서의 한 줄입니다. Debian 시스템은 현재 Linux 커널 또는 FreeBSD 커널을 쓴다고 적습니다. 커널을 갈아 끼울 수 있다고 적는 이상 배포판과 커널은 같은 것이 아닙니다. Debian 을 깔면 Linux 커널을 포함한 묶음을 깐 것입니다. Linux 는 그 묶음의 한 층입니다.

이름을 어떻게 부를지에는 다른 주장이 있습니다. 자유소프트웨어재단의 Richard Stallman 은 널리 Linux 라고 불리는 그 시스템이 사실은 GNU 시스템이라고 적습니다. Linux 는 커널이며 기계의 자원을 다른 프로그램들에 배분하는 프로그램이라는 것입니다. 커널은 운영체제의 필수 부분입니다. 다만 그것만으로는 쓸모가 없다고 적습니다. 완전한 운영체제라는 맥락 안에서만 기능한다는 것입니다. 그래서 전체는 GNU 에 Linux 를 더한 GNU/Linux 이며 이른바 Linux 배포판들은 전부 GNU/Linux 배포판이라고 적습니다. 이것은 당사자의 주장입니다. 위 판정은 Debian 문서 쪽을 근거로 삼았습니다.

관련 항목

유저스페이스에 여는 시스템 콜

시스템콜 · fork · 파일 디스크립터 · epoll · API

커널이 맡는 프로세스·메모리 관리

프로세스 · 스케줄러 · 가상 메모리 · CPU

파일을 다루는 계층

VFS · ext4 · 페이지 캐시

자원을 격리·배분하는 장치

cgroup · 네임스페이스 · 컨테이너 · systemd

이것이 속하는 상위 분류

커널 · 운영체제 · 유닉스

이것을 정의하는 표준·문서

POSIX · ABI · GPL-2.0(GNU General Public License version 2 only)

이식 조건이 되는 아키텍처와 도구

x86 · ARM(Advanced RISC Machine) · SPARC · PowerPC · MIPS · S/390 · x86-64 · GCC(GNU Compiler Collection)

이것이 배포·전달되는 경로

배포 · Debian · Ubuntu · Fedora · Android

이것의 하위 종류

ACK · GKI · LTS

릴리스가 거치는 처리 단계

개발 · 병합 · 메인라인 · stable 트리