리눅스 커널

타넨바움–토르발스 논쟁

MINIX 개발자 앤드루 타넨바움와 리누스 토르발스 사이에 리눅스가 마이크로커널이 아닌 모놀리딕 커널이라는 것이 논쟁의 주제였다. 1992년 시작된 유즈넷 토론 그룹 comp.os.minix의 토론은 대체적으로 리눅스와 커널 아키텍처에 관한 것이었다. 타넨바움은 마이크로커널이 모놀리딕 커널보다 우수하므로 리눅스는 구식이 되었다고 주장했다. 전통적인 모놀리딕 커널과 달리 리눅스의 장치 드라이버들은 적재 가능 커널 모듈로 쉽게 구성할 수 있으며 시스템을 실행하는 중에 적재되거나 적재가 해제된다. 이 주제는 2006년 5월 9일 논의되었고, 2006년 5월 12일 타넨바움은 긍정적인 문장을 썼다.

대중화

리눅스 커널을 포함하는 안드로이드 운영 체제의 인기가 상승하면서 이 커널이 모바일 장치를 위한 가장 대중적인 선택이 되었고 기타 설치 기반의 모든 운영 체제와 겨루게 되었다. 과거의 여러 햇수를 포함하여 2014년 말을 기준으로 30억 대의 안드로이드 스마트폰들이 판매된 것으로 추정되었다.
수많은 컨슈머 라우터들 또한 리눅스 커널을 사용하며 그 외에 스마트 TV, 셋톱 박스, 웹캠과 같은 다양한 기타 임베디드 장치들 또한 마찬가지이다. 리눅스 커널을 포함하는 수많은 데스크톱 리눅스 배포판들이 존재하지만 리눅스 배포판의 사용률 면에서는 다른 운영 체제에 비해 낮은 편이다.

프로그래밍 언어

리눅스 커널은 어셈블리어(GCC의 AT&T 스타일 문법)로 작성된 수많은 짧은 코드와 더불어 GCC(수많은 확장과 변경 사항을 표준 C에 도입)에 의해 지원되는 C 프로그래밍 언어 버전으로 작성되어 있다. 지원되는 C 확장 덕분에 GCC는 한동안 리눅스 커널을 올바르게 빌드할 수 있는 유일한 컴파일러였다.

컴파일러 호환성

GCC는 리눅스 커널 소스의 기본 컴파일러이다. 2004년, 인텔은 자사의 C 컴파일러가 컴파일할 수 있도록 커널을 수정했다고 주장하였다. 2009년 2.6.22 커널의 수정판에서 이같은 또다른 성공이 보고되었다.
2010년 이후로 C 언어의 다른 컴파일러인 클랭으로 리눅스 커널을 빌드하려는 노력이 진행되고 있다. 2014년 4월 12일 기준으로 공식 커널은 대부분 클랭으로 컴파일이 가능하다. 이러한 노력에 따른 프로젝트의 이름은 LLVMLinux이며, 이는 클랭 기반 LLVM 컴파일러 구조를 따른 것을 뜻한다. LLVMLinux는 리눅스 커널이나 LLVM을 포크하는 것이 목적이 아니기 때문에 업스트림 프로젝트에 제출되는 패치들로 구성된 메타 프로젝트로 볼 수 있다. 클랭으로 리눅스 커널을 컴파일할 수 있음으로 인한 이점에는 GCC 대비 더 빠른 컴파일 속도가 있으며 커널 개발자들은 더 짧아진 컴파일러 시간으로 인해 더 빠른 워크플로의 이점을 취할 수 있게 된다.

인터페이스

표준을 준수하는 것은 리눅스 커널의 내부 기능에 대한 포괄적인 정책이다. 다른 규칙으로는 해당 구성 요소를 사용하는 사유(proprietary)의 사용자 공간 소프트웨어가 있을 경우에는 커널의 구성 요소가 리눅스 커널에 수용되지 않는다는 점이다.

커널-사용자공간 API

소스 코드 이식성은 표준을 준수하여 작성된 C 프로그램이 동일 표준을 준수하는 시스템에서 성공적으로 컴파일되고 실행 가능함을 보증한다. 리눅스 커널, GNU C 라이브러리, 관련 유틸리티들이 고수하려 애쓰는, 프로그램의 소스 코드 이식성을 달성하는데 초점을 둔 관련 표준들은 POSIX와 단일 유닉스 규격이다.
커널의 시스템 호출 인터페이스를 대표하는 리눅스 커널의 리눅스 커널 API는 사용 가능한 시스템 호출로 구성되어 있다.

커널-사용자공간 ABI

이진 이식성은 주어진 하드웨어 플랫폼에 맞추어 컴파일된 프로그램이라면 표준을 준수하는 기타 하드웨어 플랫폼에서 컴파일된 형태로 실행이 가능함을 보증할 수 있다. 이진 이식성은 리눅스 커널 기반의 운영 체제용 독립 소프트웨어 벤더(ISV) 응용 프로그램들의 상업적 독자 생존의 필수 요건이다. 바이너리 호환은 소스 코드 이식성보다 훨씬 더 요구사항이 많다. 즉, 2014년 2월 기준으로 바이너리 호환성과 관련된 유일한 표준은 리눅스 기본 규격(LSB)이다.

커널 내 ABI

일부 단체들은 여러 릴리스를 통해 커널 내 ABI의 정의 및 유지보수를 굳건히 지원해왔다. 이를테면 사유 커널 모듈을 출시하고 바이너리 전용 소프트웨어(예: 장치 드라이버)를 배포하는 하드웨어 제조업체들에게 이익을 준다. 그러나 리눅스 커널 개발자들은 안정적인 커널 내 ABI를 유지보수하지 않기로 했다. 이로써 리눅스 커널 개발을 더 진척시킬 수 있게 되었다.

선점

리눅스 커널은 특정한 조건에서 선점 스케줄링을 제공한다. 리눅스 커널 2.4까지 오직 사용자 프로세스들만이 선점 형태였다. 이를테면 타임 퀀텀 만기(time quantum expiration) 외에도 사용자 모드 내의 현재 프로세스의 실행은 더 높은 동적 우선 순위 프로세스가 TASK_RUNNING 상태에 진입할 때 인터럽트 처리된다. 2.6 시리즈의 리눅스 커널에 들어서면서 커널 코드를 실행하는 태스크를 인터럽트할 수 있는 기능이 추가되었으나 이를 통해서도 커널 코드의 모든 부분을 선점할 수 있는 것은 아니다.
리눅스 커널에는 각기 다른 스케줄러 클래스가 포함되어 있다. 기본적으로 커널은 2.6.23 버전의 커널에 도입된 Completely Fair Scheduler라는 이름의 스케줄러 매커니즘을 사용한다.
내부적으로 이 기본 스케줄러 클래스는 SCHED_OTHER로 알려져 있으나, 커널은 또한 POSIX를 준수하는 SCHED_FIFO(실시간 스케줄링 클래스, 즉 실시간 FIFO)와 SCHED_RR(실시간 라운드 로빈)을 포함하고 있으며, 둘 다 기본 클래스보다 더 높은 우선순위를 가진다.
실시간 리눅스 커널 패치 PREEMPT_RT를 사용함으로써, 임계영역, 인터럽트 핸들러, 인터럽트 비활성화(interrupt disable) 코드 시퀀스의 완전한 선점을 지원할 수 있다. 실시간 리눅스 커널 패치의 부분적인 메인라인 통합을 통해 이미 커널 메인라인에 일부 기능이 도입된 상황이다. 선점은 레이턴시를 개선하고, 응답 속도를 증가시키며 리눅스를 데스크톱 및 실시간 애플리케이션에 더 적합하도록 만들어준다. 구 버전의 커널은 전체 커널에 대한 동기화를 위해 이른바 빅 커널 락을 가지고 있었으며 2011년 Arnd Bergmann에 의해 최종적으로 제거되었다.
최단 마감 우선 알고리즘(EDF)을 구현하는 SCHED DEADLINE라는 이름의 추가적인 스케줄링 정책이 커널 버전 3.14에 추가되었고 2014년 3월 30일 출시되었다.

이식성

리눅스가 처음부터 이식을 위해 설계된 것은 아니지만, 현재 가장 널리 이식된 운영 체제 커널들 가운데 하나이며 ARM 아키텍처에서부터 IBM z/아키텍처 메인프레임 컴퓨터에 이르기까지 다양한 범위의 시스템에서 실행된다. 리눅스의 오리지널 386 아키텍처를 넘어선 첫 이식은 아미가 사용자들의 모토로라 68000 플랫폼에서 수행되었으며, 해당 사용자들은 커널의 주요 부분을 대체함으로써 이를 수행하였다. 토르발스가 모토로라 버전을 실제 포트가 아닌 포크의 하나이자 "리눅스 계열 운영 체제"로 간주했던 만큼 커널의 수정은 매우 중요했다.이는 토르발스가 경쟁 컴퓨팅 아키텍처로의 이식을 용이케 하기 위해 커널 코드의 재구성이 필요하다는 추진제 역할을 했다. 최초의 리눅스 보증 포트는 DEC 알파 AXP 64비트 플랫폼을 대상으로 했으며 1995년 5월 DECUS에서 시연되었고 둘 다 하나의 소스 트리에서 386과 알파를 지원한다. DEC는 같은 해 토르발스가 리눅스를 64비트로 포팅하는데 필수적인 하드웨어를 공급하는 일을 맡았다.
리눅스는 IBM의 블루 진(Blue Gene)과 그 밖의 속도가 가장 빠른 슈퍼컴퓨터(최상위의 중국 것 포함)의 주 운영 체제로서 실행된다. 2017년 11월 기준으로 전 세계 500대의 최고 속도의 슈퍼컴퓨터들 모두 여러 종류의 리눅스를 구동한다. 리눅스는 또한 애플 아이팟, 아이폰 등의 여러 휴대용 장치에도 이식되었다. 휴대전화용으로 개발된 일부 운영 체제들은 수정된 리눅스 커널 버전을 사용하며 여기에는 구글의 안드로이드, 파이어폭스 OS, HP 웹OS, 노키아 마에모, 졸라 세일피시 OS가 포함된다.

커널 패닉과 웁스

리눅스에서 패닉은 커널에 의해 감지되었으나 복구할 수 없는 시스템 오류를 말하며, 이는 사용자 공간 코드에 의해 감지된 비슷한 오류와는 반대된다. 커널 코드는 헤더 파일 sys/system.h에 위치한 panic 함수를 호출함으로써 이러한 조건을 지시하는 것이 가능하다. 그러나 대부분의 패닉들은 유효하지 않은 메모리 주소에 대한 참조 등 커널 코드 내에서 처리되지 못한 프로세서 예외의 결과물이다. 이것들은 일반적으로 패닉을 일으키게 만든 호출 체인 내의 어딘가의 버그로 인지된다. 문제가 되는 RAM 셀, 프로세스 버그로 인해 발생된 프로세스 내 산술 기능의 오류, 프로세서의 과열/손상, 소프트 오류 등의 하드웨어의 고장으로 인식할 수도 있다.
커널 내에서 치명적이지 않은 버그의 보고는 웁스라고 한다. 즉, 리눅스 커널의 올바른 동작에서 파생된 것들은 보증된 신뢰성과 함께 지속적인 운용을 허용할 수 있다. 이러한 충돌 보고들은 자동으로 수집되며 다양한 소프트웨어에 의해 상위 보고가 가능하다. 이를테면 커널웁스, ABRT (페도라), apport (우분투) 등이 있다. KernelOops.org는 이러한 보고를 수집하고 통계를 자신들의 웹사이트에 게시한다.
커널 패닉 메시지는 그래픽 데스크톱을 사용할 때 등 일부 상황에서는 눈으로 볼 수 있도록 출력되지 않을 수 있다. 이러한 조건에서 디버깅하려면 직렬 포트 콘솔을 부착하는 등의 다른 수단을 사용할 수 있다.

라이브 패치

Ksplice, kpatch, kGraft 등의 재기동 없는 업데이트도 커널에 적용할 수 있다. 라이브 커널 패치를 위한 최소한의 파운데이션은 2015년 4월 12일 출시된 커널 버전 4.0의 리눅스 커널 메인라인에 통합되었다. 주로 커널의 ftrace 기능에 기반을 둔 "livepatch"라는 이름으로 된 해당 파운데이션들은 kGraft와 kpatch를 통해 핫 패치를 지원할 수 있는 공통 코어를 형성하며 이는 핫 패치를 포함하는 커널 모듈을 위한 API, 그리고 사용자 공간 관리 유틸리티를 위한 응용 프로그램 이진 인터페이스(ABI)를 제공함으로써 이루어진다. 그러나 리눅스 커널 4.0에 포함된 공통 코어는 오직 x86 아키텍처만 지원하며 핫 패치가 적용되더라도 함수 수준의 일관성을 보증하기 위한 매커니즘은 제공하지 않는다. 2015년 4월 기준으로 kpatch와 kGraft를 리눅스 커널 메인라인에 의해 제공되는 공통 라이브 패치 코어로 이식하는 작업이 진행 중이다.

보안

커널 버그의 대부분이 잠재적인 보안 결함을 보이기 때문에 컴퓨터 보안은 리눅스 커널과 관련하여 매우 공론화된 주제이다. 이를테면 권한 확대를 허용하거나 서비스 거부 공격(DoS 공격) 벡터를 생성할 수 있다. 해가 거듭되면서 리눅스 커널에서는 이러한 수많은 결함들이 발견되어 수정되었다. 리눅스 커널 보안 개선을 위해 새로운 보안 기능들이 종종 구현된다.
비평가들은 보안 결함을 은폐하거나 적어도 이 결함들을 발표하지 않는 커널 개발자들을 비난해왔다. 즉, 2008년 리누스 토르발스는 다음과 같이 이에 대해 응답하였다:
저는 개인적으로 보안 버그를 단지 "일반적인 버그"로 치부합니다. 저는 이 버그들을 은폐하는 것은 아니지만 이것들을 추적하여 특별하다고 발표하는 것이 좋은 생각인지 잘 모르겠습니다.
리눅스 배포판들은 일반적으로 리눅스 커널의 취약점을 수정하기 위한 보안 업데이트를 출시한다. 수많은 배포판들은 장기간 지원 릴리스를 제공하며 오랜 기간 특정 리눅스 커널 버전의 보안 업데이트를 받을 수 있게 하고 있다.

기능 역사

2012년 12월, 토르발스는 i386 프로세서 지원을 제거함으로써 커널 복잡도를 줄이기로 마음먹었고, 이로써 3.7 커널 시리즈가 오리지널 프로세서를 지원하는 마지막이 된다. 동일한 시리즈는 ARM 프로세서 지원을 통합하였다.
버전 3.11은 2013년 9월 2일 출시되었고, 수많은 새 기능들을 추가하고 있는데, 이를테면 open(2)
의 임시 파일 취약성을 줄이기 위한 새로운 O_TMPFILE, 실험적인 AMD 라데온 동적 전력 관리, 레이턴시가 적은 네트워크 폴링, zswap(압축된 스왑 캐시)가 있다.
2.6.39부터 3.0, 3.19부터 4.0에 이르는 번호 변경은 의미있는 기술적 차이를 수반하지는 않는다. 메이저 버전 번호는 커다란 마이너 번호를 회피하기 위해 증가시킨 것이다.