리눅스 커널은 1991년 리누스 토르발스가 자신의 개인용 컴퓨터를 위해 고안되어 개발[5] 되었고 크로스 플랫폼의 의도는 없었으나 그 이후로 다른 운영 체제나 커널 대비 더 다양한 컴퓨터 아키텍처를 지원하도록 확장되었다. 리눅스는 급속도로 기타 자유 소프트웨어 프로젝트, 특히 GNU 운영 체제로 이 커널을 채택한 개발자들과 사용자들을 매혹시켰다.[6] 리눅스 커널은 1,200개 이상의 회사의 12,000명에 가까운 프로그래머들의 기여를 받아왔으며, 여기에는 최대 소프트웨어 및 하드웨어 벤더들 일부가 포함된다.[7][8]
리눅스 커널 API는 사용자 프로그램들이 커널과 통신하는 API로서 매우 안정적이고 유저스페이스 프로그램(GUI를 갖추고 다른 API에 의존하는 일부 프로그램)을 망가트리지 않는다는 것을 뜻한다. 커널 기능의 일부로서 장치 드라이버들은 하드웨어를 제어한다. 즉, 주류 장치 드라이버들은 매우 안정적임을 뜻한다. 그러나 다른 수많은 커널과 운영 체제와 달리 커널과 적재 가능 커널 모듈(LKM) 간의 인터페이스가 매우 안정적으로 설계되었다는 것을 뜻하는 것은 아니다.[9]
386(486) AT 클론을 위한 (자유) 운영 체제를 만들고 있습니다.(취미일 뿐이며 gnu처럼 크고 프로페셔널하진 않아요) 4월부터 진행 중이며 준비 작업을 시작하고 있습니다. minix에서 제 운영 체제가 무언가를 닮았는지(타당한 이유로 파일 시스템의 동일한 물리적 설계), 사람들이 좋아하고 싫어하는 바에 대한 의견을 바랍니다.
저는 현재 bash(1.08)와 gcc(1.40)을 포팅하였으며 동작하는 것으로 보입니다. 이 말은 수개월 안에 뭔가 실용적인 것을 하겠다는 이야기입니다. (중략) 그래요, minix 코드는 모두 자유이고 멀티스레드 fs가 포함됩니다. 포팅은 불가능하며(386 태스크 교환 등을 사용) AT 하드디스크 외에는 다른 것들은 지원하지 않을 겁니다. 왜냐하면 제가 가진 것이 그게 다거든요. :-(.
(중략) 대부분은 C로 되어있지만 대부분의 사람들은 제가 C로 쓴 것을 호출하지 않을 겁니다. 386에 관해 제게 가르쳐준 프로젝트이기도 해서 제가 찾을 수 있었던 386의 가능한 모든 기능을 사용합니다. 이미 언급했듯이 페이징(아직 디스크는 아님)과 세그먼테이션을 위해 MMU를 사용합니다. 정말로 386에 의존하는 세그먼테이션입니다. (모든 태스크는 코드 및 데이터를 위해 64메가바이트의 세그먼트를 취하고 있으며 4Gb에 최대 64개의 태스크가 들어갑니다)
그 뒤로 수많은 사람들이 해당 프로젝트에 코드를 기여하였다. 초기에 MINIX 커뮤니티는 리눅스 커널에 코드와 아이디어를 기여하였다. 당시 GNU 프로젝트는 자유 운영 체제에 필요한 구성 요소들 중 다수를 만들어냈지만 자체 커널 GNU 허드는 완전하지 않았고 이용이 불가능했다. BSD 운영 체제는 법적 문제로부터 자유롭지 못했다. 초기 버전의 제한적인 기능에도 불구하고 리눅스는 급속도로 개발자들과 사용자들을 모아나갔다.
1991년 9월, 버전 0.01의 리눅스 커널이 핀란드 대학교와 FUNET(리서치 네트워크)의 FTP 서버(ftp.funet.fi)에 공개되었다. 10,239줄의 코드였다. 1991년 10월, 버전 0.02의 리눅스 커널이 출시되었다.[15]
1991년 12월, 리눅스 커널 0.11이 출시되었다. 이 버전은 셀프 호스팅이 되는 최초 버전이었으며 리눅스 커널 0.11은 동일한 커널 버전을 실행 중인 컴퓨터에 의해 컴파일할 수 있었다. 토르발스가 1992년 2월에 버전 0.12를 출시하였을 때 상업적 배포를 허가하지 않았던 자신의 과거 자체 초안 라이선스를 넘어서서 GNU GPL을 채택했다.[16]
1992년 1월 19일, 새로운 뉴스그룹 alt.os.linux에 첫 게시글이 제출되었다.[17] 1992년 3월 31일, 뉴스그룹 이름은 comp.os.linux로 바뀌었다.[18]
X 윈도 시스템이 리눅스에 포팅되었으며, 이로써 1992년 3월 리눅스 버전 0.95는 X를 실행할 수 있는 최초 버전이 되었다. 0.1에서 0.9x로의 큰 버전 번호 점프로 인해 크게 빠진 부분이 없이 버전 1.0이 임박한 것처럼 예측되었다. 그러나 이는 사실이 아닌 것으로 드러났으며 1993년부터 1994년 초까지 0.99의 15개의 개발판이 등장하였다.
1994년 3월 14일, 리눅스 커널 1.0.0이 출시되었으며 그 코드 줄 수는 176,250줄이다. 1995년 3월, 리눅스 커널 1.2.0이 출시되었으며, 코드 줄 수는 310,950줄이다.
리눅스 커널 버전 2는 1996년 6월 9일 출시되었으며 버전 2 헤더 아래에 추가 메이저 버전이 잇따라 출시되었다:
1999년 1월 25일 – 리눅스 커널 2.2.0 릴리스 (1,800,847 줄)
1999년 12월 18일 – IBM 메인프레임 패치(2.2.13용) 게시. 리눅스 커널이 기업급 머신에서 사용될 수 있게 허용
2001년 1월 4일 – 리눅스 커널 2.4.0 릴리스 (3,377,902 줄)
2003년 12월 17일 – 리눅스 커널 2.6.0 릴리스 (5,929,913 줄)
2004년을 기점으로 릴리스 프로세스가 변경되었으며 새로운 커널들이 2~3개월마다 정기적인 일정에 따라 출시를 시작했으며, 번호는 2.6.0, 2.6.1부터 2.6.39까지 이르렀다.
2011년 7월 21일, 토르발스는 리눅스 커널 3.0 릴리스를 발표하였다: "Gone are the 2.6.<bignum> days".[19] 이러한 버전 상승은 리눅스 2.6.39 대비 큰 기술적 변화에 대한 것은 아니었다.[20] 단지 커널의 20주년을 표현한 것이다.[21] 시간 기반 릴리스 프로세스는 동일하게 유지되었다.
버전 3.10의 리눅스 커널은 2013년 6월 출시되었으며 15,803,499줄이 포함되었으며,[22] 버전 4.1은 2015년 6월 출시되었고 약 14,000명의 프로그래머가 기여한 코드를 포함 19,500,000줄 이상으로 성장하였다.[23]
MINIX 개발자 앤드루 타넨바움와 리누스 토르발스 사이에 리눅스가 마이크로커널이 아닌 모놀리딕 커널이라는 것이 논쟁의 주제였다.[24] 1992년 시작된 유즈넷 토론 그룹 comp.os.minix의 토론은 대체적으로 리눅스와 커널 아키텍처에 관한 것이었다.[25] 타넨바움은 마이크로커널이 모놀리딕 커널보다 우수하므로 리눅스는 구식이 되었다고 주장했다. 전통적인 모놀리딕 커널과 달리 리눅스의 장치 드라이버들은 적재 가능 커널 모듈로 쉽게 구성할 수 있으며 시스템을 실행하는 중에 적재되거나 적재가 해제된다. 이 주제는 2006년 5월 9일 논의되었고,[26] 2006년 5월 12일 타넨바움은 긍정적인 문장을 썼다.[27]
대중화
리눅스 커널을 포함하는 안드로이드 운영 체제의 인기가 상승하면서 이 커널이 모바일 장치를 위한 가장 대중적인 선택이 되었고 기타 설치 기반의 모든 운영 체제와 겨루게 되었다.[28][29][30] 과거의 여러 햇수를 포함하여 2014년 말을 기준으로 30억 대의 안드로이드 스마트폰들이 판매된 것으로 추정되었다.
수많은 컨슈머 라우터들 또한 리눅스 커널을 사용하며[31] 그 외에 스마트 TV, 셋톱 박스, 웹캠과 같은 다양한 기타 임베디드 장치들 또한 마찬가지이다. 리눅스 커널을 포함하는 수많은 데스크톱 리눅스 배포판들이 존재하지만 리눅스 배포판의 사용률 면에서는 다른 운영 체제에 비해 낮은 편이다.
장치 드라이버와 커널 확장 기능은 커널 공간(수많은 CPU구조에서 링 0)에서 실행되며, 하드웨어에 대한 모든 접근 권한이 있으나 사용자 공간에서의 실행은 일부 예외가 있는데 이를테면 FUSE/CUSE 기반 파일 시스템들, UIO의 일부가 그러하다.[34][35] 대부분의 사람들이 리눅스와 함께 사용하는 그래픽스 시스템은 커널 내에서 실행되지 않는다. 표준 모놀리딕 커널과 달리 장치 드라이버는 쉽게 모듈로 구성되며 시스템이 실행 중인 동안에 적재되거나 적재가 해제된다. 또, 표준 모놀리딕 커널과 달리 장치 드라이버들은 특정한 조건에서 선점이 가능하다. 즉, 이 기능은 하드웨어 인터럽트를 정확히 관리하고 대칭형 다중 처리를 더 양호하게 지원하기 위해 추가되었다.[33] 리눅스 커널은 자체적으로 바이너리 커널 인터페이스가 없다.[36]
하드웨어 또한 파일 계층에 통합되어 있다. 장치 드라이버들은 /dev 또는 /sys 디렉터리의 엔트리를 통해 사용자 응용 프로그램들과 통신한다.[37] 프로세스 정보 또한 /proc 디렉터리를 통해 파일 시스템에 매핑된다.[37]
리눅스 커널은 어셈블리어(GCC의 AT&T 스타일 문법)로 작성된 수많은 짧은 코드와 더불어 GCC(수많은 확장과 변경 사항을 표준 C에 도입)에 의해 지원되는 C 프로그래밍 언어 버전으로 작성되어 있다. 지원되는 C 확장 덕분에 GCC는 한동안 리눅스 커널을 올바르게 빌드할 수 있는 유일한 컴파일러였다.
컴파일러 호환성
GCC는 리눅스 커널 소스의 기본 컴파일러이다. 2004년, 인텔은 자사의 C 컴파일러가 컴파일할 수 있도록 커널을 수정했다고 주장하였다.[38] 2009년 2.6.22 커널의 수정판에서 이같은 또다른 성공이 보고되었다.[39][40]
2010년 이후로 C 언어의 다른 컴파일러인 클랭으로 리눅스 커널을 빌드하려는 노력이 진행되고 있다.[41] 2014년 4월 12일 기준으로 공식 커널은 대부분 클랭으로 컴파일이 가능하다.[42][43] 이러한 노력에 따른 프로젝트의 이름은 LLVMLinux이며, 이는 클랭 기반 LLVM 컴파일러 구조를 따른 것을 뜻한다.[44] LLVMLinux는 리눅스 커널이나 LLVM을 포크하는 것이 목적이 아니기 때문에 업스트림 프로젝트에 제출되는 패치들로 구성된 메타 프로젝트로 볼 수 있다. 클랭으로 리눅스 커널을 컴파일할 수 있음으로 인한 이점에는 GCC 대비 더 빠른 컴파일 속도가 있으며 커널 개발자들은 더 짧아진 컴파일러 시간으로 인해 더 빠른 워크플로의 이점을 취할 수 있게 된다.[45]
소스 코드 이식성은 표준을 준수하여 작성된 C 프로그램이 동일 표준을 준수하는 시스템에서 성공적으로 컴파일되고 실행 가능함을 보증한다. 리눅스 커널, GNU C 라이브러리, 관련 유틸리티들이 고수하려 애쓰는, 프로그램의 소스 코드 이식성을 달성하는데 초점을 둔 관련 표준들은 POSIX와 단일 유닉스 규격이다.
커널의 시스템 호출 인터페이스를 대표하는 리눅스 커널의 리눅스 커널 API는 사용 가능한 시스템 호출로 구성되어 있다.
이진 이식성은 주어진 하드웨어 플랫폼에 맞추어 컴파일된 프로그램이라면 표준을 준수하는 기타 하드웨어 플랫폼에서 컴파일된 형태로 실행이 가능함을 보증할 수 있다. 이진 이식성은 리눅스 커널 기반의 운영 체제용 독립 소프트웨어 벤더(ISV) 응용 프로그램들의 상업적 독자 생존의 필수 요건이다. 바이너리 호환은 소스 코드 이식성보다 훨씬 더 요구사항이 많다. 즉, 2014년 2월 기준으로 바이너리 호환성과 관련된 유일한 표준은 리눅스 기본 규격(LSB)이다.
커널 내 API
각기 다른 하위 시스템들과 하위 시스템들의 하위 시스템들 간 활용되는 커널 내부 API가 여럿 있다. 이들 가운데 일부는 여러 릴리스를 통해 안정적으로 유지되고 있고 다른 것들은 그렇지 않다. 커널 내 API와 관련한 어떠한 보증도 없다. 유지보수자들과 기여자들은 언제든지 이것들을 자유로이 늘려나가거나 바꿀 수 있다.[47]
커널 내 API의 예에는 다음 계열의 장치 드라이버를 위한 소프트웨어 프레임워크/API를 포함한다.
일부 단체들은 여러 릴리스를 통해 커널 내 ABI의 정의 및 유지보수를 굳건히 지원해왔다. 이를테면 사유 커널 모듈을 출시하고 바이너리 전용 소프트웨어(예: 장치 드라이버)를 배포하는 하드웨어 제조업체들에게 이익을 준다. 그러나 리눅스 커널 개발자들은 안정적인 커널 내 ABI를 유지보수하지 않기로 했다.[49] 이로써 리눅스 커널 개발을 더 진척시킬 수 있게 되었다.
리눅스 커널은 특정한 조건에서 선점 스케줄링을 제공한다. 리눅스 커널 2.4까지 오직 사용자 프로세스들만이 선점 형태였다. 이를테면 타임 퀀텀 만기(time quantum expiration) 외에도 사용자 모드 내의 현재 프로세스의 실행은 더 높은 동적 우선 순위 프로세스가 TASK_RUNNING 상태에 진입할 때 인터럽트 처리된다.[51] 2.6 시리즈의 리눅스 커널에 들어서면서 커널 코드를 실행하는 태스크를 인터럽트할 수 있는 기능이 추가되었으나 이를 통해서도 커널 코드의 모든 부분을 선점할 수 있는 것은 아니다.[52]
리눅스 커널에는 각기 다른 스케줄러 클래스가 포함되어 있다.[53] 기본적으로 커널은 2.6.23 버전의 커널에 도입된 Completely Fair Scheduler라는 이름의 스케줄러 매커니즘을 사용한다.[54]
내부적으로 이 기본 스케줄러 클래스는 SCHED_OTHER로 알려져 있으나, 커널은 또한 POSIX를 준수하는[55]SCHED_FIFO(실시간 스케줄링 클래스, 즉 실시간 FIFO)와 SCHED_RR(실시간 라운드 로빈)을 포함하고 있으며, 둘 다 기본 클래스보다 더 높은 우선순위를 가진다.[53]
실시간 리눅스 커널 패치 PREEMPT_RT를 사용함으로써, 임계영역, 인터럽트 핸들러, 인터럽트 비활성화(interrupt disable) 코드 시퀀스의 완전한 선점을 지원할 수 있다.[56] 실시간 리눅스 커널 패치의 부분적인 메인라인 통합을 통해 이미 커널 메인라인에 일부 기능이 도입된 상황이다.[57] 선점은 레이턴시를 개선하고, 응답 속도를 증가시키며 리눅스를 데스크톱 및 실시간 애플리케이션에 더 적합하도록 만들어준다. 구 버전의 커널은 전체 커널에 대한 동기화를 위해 이른바 빅 커널 락을 가지고 있었으며 2011년 Arnd Bergmann에 의해 최종적으로 제거되었다.[58]
리눅스가 처음부터 이식을 위해 설계된 것은 아니지만,[14][61] 현재 가장 널리 이식된 운영 체제 커널들 가운데 하나이며 ARM 아키텍처에서부터 IBM z/아키텍처메인프레임 컴퓨터에 이르기까지 다양한 범위의 시스템에서 실행된다. 리눅스의 오리지널 386 아키텍처를 넘어선 첫 이식은 아미가 사용자들의 모토로라 68000 플랫폼에서 수행되었으며, 해당 사용자들은 커널의 주요 부분을 대체함으로써 이를 수행하였다. 토르발스가 모토로라 버전을 실제 포트가 아닌 포크의 하나이자 "리눅스 계열 운영 체제"로 간주했던 만큼 커널의 수정은 매우 중요했다.[61] 이는 토르발스가 경쟁 컴퓨팅 아키텍처로의 이식을 용이케 하기 위해 커널 코드의 재구성이 필요하다는 추진제 역할을 했다. 최초의 리눅스 보증 포트는 DEC알파 AXP 64비트 플랫폼을 대상으로 했으며 1995년 5월 DECUS에서 시연되었고[62] 둘 다 하나의 소스 트리에서 386과 알파를 지원한다.[61] DEC는 같은 해 토르발스가 리눅스를 64비트로 포팅하는데 필수적인 하드웨어를 공급하는 일을 맡았다.[63]
리눅스에서 패닉은 커널에 의해 감지되었으나 복구할 수 없는 시스템 오류를 말하며, 이는 사용자 공간 코드에 의해 감지된 비슷한 오류와는 반대된다. 커널 코드는 헤더 파일 sys/system.h에 위치한 panic 함수를 호출함으로써 이러한 조건을 지시하는 것이 가능하다. 그러나 대부분의 패닉들은 유효하지 않은 메모리 주소에 대한 참조 등 커널 코드 내에서 처리되지 못한 프로세서 예외의 결과물이다. 이것들은 일반적으로 패닉을 일으키게 만든 호출 체인 내의 어딘가의 버그로 인지된다. 문제가 되는 RAM 셀, 프로세스 버그로 인해 발생된 프로세스 내 산술 기능의 오류, 프로세서의 과열/손상, 소프트 오류 등의 하드웨어의 고장으로 인식할 수도 있다.
커널 내에서 치명적이지 않은 버그의 보고는 웁스라고 한다. 즉, 리눅스 커널의 올바른 동작에서 파생된 것들은 보증된 신뢰성과 함께 지속적인 운용을 허용할 수 있다.[68] 이러한 충돌 보고들은 자동으로 수집되며 다양한 소프트웨어에 의해 상위 보고가 가능하다. 이를테면 커널웁스,[69] ABRT (페도라)[70], apport (우분투) 등이 있다. KernelOops.org는 이러한 보고를 수집하고 통계를 자신들의 웹사이트에 게시한다.[71]
커널 패닉 메시지는 그래픽 데스크톱을 사용할 때 등 일부 상황에서는 눈으로 볼 수 있도록 출력되지 않을 수 있다. 이러한 조건에서 디버깅하려면 직렬 포트 콘솔을 부착하는 등의 다른 수단을 사용할 수 있다.
라이브 패치
Ksplice, kpatch, kGraft 등의 재기동 없는 업데이트도 커널에 적용할 수 있다. 라이브 커널 패치를 위한 최소한의 파운데이션은 2015년 4월 12일 출시된 커널 버전 4.0의 리눅스 커널 메인라인에 통합되었다. 주로 커널의 ftrace 기능에 기반을 둔 "livepatch"라는 이름으로 된 해당 파운데이션들은 kGraft와 kpatch를 통해 핫 패치를 지원할 수 있는 공통 코어를 형성하며 이는 핫 패치를 포함하는 커널 모듈을 위한 API, 그리고 사용자 공간 관리 유틸리티를 위한 응용 프로그램 이진 인터페이스(ABI)를 제공함으로써 이루어진다. 그러나 리눅스 커널 4.0에 포함된 공통 코어는 오직 x86 아키텍처만 지원하며 핫 패치가 적용되더라도 함수 수준의 일관성을 보증하기 위한 매커니즘은 제공하지 않는다. 2015년 4월 기준으로 kpatch와 kGraft를 리눅스 커널 메인라인에 의해 제공되는 공통 라이브 패치 코어로 이식하는 작업이 진행 중이다.[72][73][74]
보안
커널 버그의 대부분이 잠재적인 보안 결함을 보이기 때문에 컴퓨터 보안은 리눅스 커널과 관련하여 매우 공론화된 주제이다. 이를테면 권한 확대를 허용하거나 서비스 거부 공격(DoS 공격) 벡터를 생성할 수 있다. 해가 거듭되면서 리눅스 커널에서는 이러한 수많은 결함들이 발견되어 수정되었다.[75] 리눅스 커널 보안 개선을 위해 새로운 보안 기능들이 종종 구현된다.[76][77]
비평가들은 보안 결함을 은폐하거나 적어도 이 결함들을 발표하지 않는 커널 개발자들을 비난해왔다. 즉, 2008년 리누스 토르발스는 다음과 같이 이에 대해 응답하였다:[78][79]
저는 개인적으로 보안 버그를 단지 "일반적인 버그"로 치부합니다. 저는 이 버그들을 은폐하는 것은 아니지만 이것들을 추적하여 특별하다고 발표하는 것이 좋은 생각인지 잘 모르겠습니다.
리눅스 배포판들은 일반적으로 리눅스 커널의 취약점을 수정하기 위한 보안 업데이트를 출시한다. 수많은 배포판들은 장기간 지원 릴리스를 제공하며 오랜 기간 특정 리눅스 커널 버전의 보안 업데이트를 받을 수 있게 하고 있다.
기능 역사
2012년 12월, 토르발스는 i386 프로세서 지원을 제거함으로써 커널 복잡도를 줄이기로 마음먹었고, 이로써 3.7 커널 시리즈가 오리지널 프로세서를 지원하는 마지막이 된다.[80][81] 동일한 시리즈는 ARM 프로세서 지원을 통합하였다.[82]
버전 3.11은 2013년 9월 2일 출시되었고,[83] 수많은 새 기능들을 추가하고 있는데, 이를테면 open(2)
의 임시 파일 취약성을 줄이기 위한 새로운 O_TMPFILE, 실험적인 AMD 라데온 동적 전력 관리, 레이턴시가 적은 네트워크 폴링, zswap(압축된 스왑 캐시)가 있다.[84]
2.6.39부터 3.0, 3.19부터 4.0에 이르는 번호 변경은 의미있는 기술적 차이를 수반하지는 않는다. 메이저 버전 번호는 커다란 마이너 번호를 회피하기 위해 증가시킨 것이다.[19][85]
개발
기술적 문제로 인해 그래프를 일시적으로 사용할 수 없습니다. 파브리케이터와 미디어위키 위키에 더 자세한 정보가 있습니다.
↑Kroah-Hartman, Greg. “The Linux Kernel Driver Interface”. 《Linux Kernel Documentation》. 21 December 2016에 원본 문서에서 보존된 문서. 20 January 2016에 확인함. This is being written to try to explain why Linux does not have a binary kernel interface, nor does it have a stable kernel interface.
↑“Linux Kernel Copying”. 2012년 12월 21일에 원본 문서에서 보존된 문서. 2013년 9월 25일에 확인함. Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.
↑Torvalds, Linus (2000년 9월 8일). “Linux-2.4.0-test8”. 《LKML》 (메일링 리스트) (lkml.iu.edu). 2015년 11월 21일에 확인함. The only one of any note that I'd like to point out directly is the clarification in the COPYING file, making it clear that it's only _that_particular version of the GPL that is valid for the kernel. This should not come as any surprise, as that's the same license that has been there since 0.12 or so, but I thought I'd make that explicit
↑Kroah-Hartman, Greg (2010년 2월 2일). “Android and the Linux kernel community”. 2010년 2월 3일에 확인함. This means that any drivers written for Android hardware platforms, can not get merged into the main kernel tree because they have dependencies on code that only lives in Google's kernel tree, causing it to fail to build in the kernel.org tree. Because of this, Google has now prevented a large chunk of hardware drivers and platform code from ever getting merged into the main kernel tree. Effectively creating a kernel branch that a number of different vendors are now relying on.
↑"Kernel 1.0 Source Code Release". Retrieved 7 October 2008.
↑Kernel 1.2 Source Code Release". Retrieved 27 October 2008.
↑Torvalds, Linus (9 June 1996). "Linux 2.0 really _is_ released..". LKML (Mailing list). Retrieved 8 March 2015.
↑Torvalds, Linus (20 January 1999). "2.2.0-final". LKML (Mailing list). Retrieved 8 March 2015
↑"The Wonderful World of Linux 2.2". 26 January 1999. Retrieved 27 October 2008.
↑"The Wonderful World of Linux 2.4". Retrieved 27 October 2008.
↑Torvalds, Linus (17 December 2003). "Linux 2.6.0". LKML (Mailing list). Retrieved 28 February 2015.
↑"proc(5) - Linux manual page" (see /proc/sys/kernel/pid_max).
↑"Index of /pub/linux/kernel/v2.6". Kernel.org. Retrieved 2 March 2014.
↑Torvalds, Linus (30 May 2011). "Linux 3.0-rc1". LKML (Mailing list). Retrieved 1 July 2013.
↑Vaughan-Nichols, Steven J. (13 December 2012). "Good-Bye 386: Linux to drop support for i386 chips with next major release". ZDNet. CBS Interactive. Retrieved 6 February 2013.
↑Vaughan-Nichols, Steven J. (11 December 2012). "Linux 3.7 arrives, ARM developers rejoice". ZDNet. CBS Interactive. Retrieved 6 February 2013.
↑Torvalds, Linus (2 September 2013). "Linux 3.11". LKML (Mailing list). Retrieved 3 September 2013.
↑"Linux 3.11". kernelnewbies.org. 2 September 2013. Retrieved 21 January 2014.