본문 바로가기
리눅스

(번역) Linux kernel

by 다움위키 2025. 2. 24.

원문 보기: https://dawoum.duckdns.org/wiki/Linux_kernel

 

Original article: w:Linux kernel

 

리눅스 커널은 자유와 오픈-소스,  유닉스-계열 커널로 전 세계 많은 컴퓨터 시스템에서 사용되고 있습니다. 그 커널은 1991년 Linus Torvalds에 의해 만들어졌고 곧 유닉스에 대한 무료 대체품으로 만들어진 GNU 운영 시스템 (OS)에 대해 커널로 채택되었습니다. 1990년대 후반부터, 그것은 많은 운영 시스템 배포판에 포함되어 왔으며, 그 중 다수가 리눅스라고 불립니다. 그러한 리눅스 커널 운영 시스템 중 하나가 많은 모바일 및 임베디드 기기에 사용되는 안드로이드입니다.

대부분의 커널 코드는 표준 C를 넘어서는 확장 기능을 갖춘 GNU 컴파일러 컬렉션 (GCC)에 의해 지원하는 C로 작성되었습니다. 그 코드는 역시 메모리 사용 최적화와 작업 실행과 같은 아키텍처-별 논리를 위한 어셈블리 코드도 포함하고 있습니다.  커널은 모듈이 소프트웨어 구성 요소로 통합될 수 있음을 만족하는 모듈러 디자인을 가지고 있습니다 – 여기에는 동적으로 로드되는 것도 포함됩니다. 커널은 전체 OS가 커널 공간에서 실행되므로 아키텍처 측면에서 모놀리식입니다.

리눅스는 GNU General Public License version 2에 따라 제공되지만, 다른 호환 라이선스 아래에서 파일을 포함하고 있습니다.

History

1991년 4월, 헬싱키 대학교의 21세 컴퓨터 과학과 학생, Linus Torvalds는 UNIX에 의해 영감을 받아 개인용 컴퓨터에 대한 운영 시스템 작업을 시작했습니다. 그는 Intel 80386 어셈블리 언어에서 작업 전환기와 터미널 드라이버로 시작했습니다. 1991년 8월 25일, Torvalds는 Usenet의 뉴스그룹, comp.os.minix에 다음을 게시했습니다:

저는 386(486) AT 클론을 위한 (자유) 운영 시스템 (그저 취미일 뿐이고, GNU처럼 크고 전문적이지는 않을 겁니다)을 만들고 있습니다. 이것은 4월부터 준비해 왔고, 이제 막 시작되고 있습니다. 저는 사람들이 미닉스에서 좋아하는 점/싫어하는 점에 대한 임의의 피드백을 부탁드리는데, 왜냐하면 제 OS가 미닉스와 어느 정도 비슷하기 때문입니다 ((실용적인 이유로 인해) 파일 시스템의 물리적 레이아웃이 같습니다).
저는 현재 bash(1.08)와 gcc(1.40)를 이식했고, 잘 작동하는 듯합니다. 이것은 제가 몇 달 안에 실용적인 것을 얻을 것임을 의미합니다 [...]
네 - 그것은 미닉스 코드가 전혀 없고, 멀티-스레드 fs를 가집니다. 그것은 이식성이 없고 [sic] (386 작업 전환 등을 사용함), AT-하드디스크 외에는 다른 것을 지원할 가능성은 거의 없는데, 왜냐하면 제가 가진 게 그것뿐이기 때문입니다 :-(.

1991년 9월 17일, Torvalds는 리눅스 0.01 버전을 준비하고 핀란드 대학 및 연구 네트워크 (FUNET)의 FTP 서버 – "ftp.funet.fi"를 설치했습니다. 그 코드는 컴파일하고 테스트하기 위해 Minix를 여전히 필요로 했기 때문에 실행 파일조차 없었습니다.

1991년 10월 5일, Torvalds는 리눅스의 첫 번째 "공식" 버전, 버전 0.02를 발표했습니다.

제가 한 달 전에 말했듯이, 저는 AT-386 컴퓨터에 대해 Minix-유사 프로그램의 자유 버전을 작업하고 있습니다. 그것은 마침내 사용 가능한 단계에 도달했고 (비록 원하는 바에 따라 그렇지 않을 수도 있지만), 저는 더 널리 배포하기 위해 소스를 공개할 의향이 있습니다. 그것은 아직 0.02 버전이지만...저는 그것 아래에서 bash, gcc, gnu-make, gnu-sed, compress, 등을 성공적으로 실행했습니다.

리눅스는 MINIX 커뮤니티를 포함한 많은 개발자가 프로젝트에 기여하면서 빠르게 성장했습니다. 당시, GNU 프로젝트는 자유 UNIX 대체물, NU OS에 대한 많은 구성 요소를 완성했지만, 그것의 커널, GNU Hurd는 불완전했습니다. 그 프로젝트는 OS에 리눅스 커널을 채택했습니다.

Torvalds는 커널이 아직 일반적인 용도로 의도되지 않았음을 나타내기 위해 커널의 주요 버전 0을 지정했습니다. 1991년 12월에 출시된 버전 0.11은 리눅스 커널을 실행하는 컴퓨터에서 컴파일된 자체-호스팅된 최초의 버전이었습니다.

Torvalds가 1992년 2월에 버전 0.12를 출시했을 때, 그는 상업적 재배포를 허용하지 않았던 그의 이전의 자체-초안 라이선스 대신 GNU General Public License version 2 (GPLv2)를 채택했습니다. 유닉스와 달리, 리눅스의 모든 소스 파일은 장치 드라이버를 포함하여 자유롭게 사용할 수 있습니다.

리눅스의 초기 성공은 전 세계의 프로그래머와 테스터에 의해 주도되었습니다. 필요에 따라 커널 주소 공간의 진입점 역할을 하는 libC를 통해, POSIX API의 지원과 함께, 리눅스는 유닉스에 대해 개발되어 온 소프트웨어와 응용 프로그램을 실행할 수 있었습니다.

1992년 1월 19일, 새로운 뉴스그룹 alt.os.linux에 첫 번째 게시물이 제출되었습니다. 1992년 3월 31일, 뉴스그룹 이름이 comp.os.linux로 변경되었습니다.

리눅스가 마이크로-커널이 아닌 모놀리식 커널이라는 사실은 MINIX의 제작자 Andrew S. Tanenbaum과 Torvalds 사이의 토론 주제였습니다. Tanenbaum–Torvalds 논쟁은 1992년 Usenet 그룹 comp.os.minix에서 커널 아키텍처에 대한 일반적인 토론으로 시작되었습니다.

버전 0.95는 X Window System을 실행할 수 있는 최초의 버전이었습니다. 1994년 3월, 리눅스 1.0.0이 176,250줄의 코드와 함께 출시되었습니다. 버전 번호에 의해 알 수 있듯이, 그것은 프로덕션 환경에 적합하다고 여겨진 최초의 버전이었습니다. 1996년 6월, 1.3이 출시된 후, Torvalds는 리눅스가 새로운 주요 번호를 보증할 만큼 충분히 발전했다고 판단했고, 다음 릴리스를 버전 2.0.0으로 지정할 것이라고 결정했습니다. 2.0의 주요 기능에는 대칭적 멀티프로세싱 (SMP), 더 많은 프로세서 유형 지원, 및 특정 하드웨어 대상 선택 지원과 아키텍처-별 기능과 최적화 활성화 지원이 포함되었습니다. kbuild의 make *config 명령의 가족은 임시 커널 실행-파일 (vmlinux) 및 로드 가능한 모듈을 빌드하기 위한 옵션을 활성화하고 구성합니다.

1999년 1월 20일에 출시된 버전 2.2는 잠금 세분성과 SMP 관리를 개선하고, m68k, PowerPC, Sparc64, Alpha, 및 기타 64-비트 플랫폼 지원을 추가했습니다. 게다가, 그것은 Microsoft의 NTFS 읽기-전용 기능을 포함한 새로운 파일 시스템을 추가했습니다. 1999년에, IBM은 S/390 아키텍처를 지원하기 위해 리눅스 2.2.13 코드에 대한 패치를 발표했습니다.

2001년 1월 4일에 출시된 버전 2.4.0에는[34] ISA 플러그 앤 플레이, USB, 및 PC 카드에 대한 지원이 포함되었습니다. 리눅스 2.4에서는 Pentium 4 및 Itanium (후자는 Intel과 Hewlett-Packard에 의해 이전 PA-RISC를 대체하기 위해 공동 개발된 ia64 ISA를 도입)과, 최신 64-비트 MIPS 프로세서에 대한 지원이 추가되었습니다. 2.4.x에 대한 개발은 Bluetooth, Logical Volume Manager (LVM) 버전 1, RAID 지원, InterMezzo 및 ext3 파일 시스템에 대한 지원을 포함하여, 시리즈 전체에서 더 많은 기능이 제공되었다는 점에서 약간 변경되었습니다.

버전 2.6.0은 2003년 12월 17일에 출시되었습니다. 2.6.x에 대한 개발은 시리즈 전체에 걸쳐 새로운 기능을 포함하는 방향으로 더욱 변경되었습니다. 2.6 시리즈에서 변경된 내용은 다음과 같습니다: μClinux를 메인라인 커널 소스에 통합, PAE 지원, 여러 새로운 CPU 라인 지원, Advanced Linux Sound Architecture (ALSA)를 메인라인 커널 소스에 통합, 최대 232명의 사용자 지원 (이전에는 216명), 최대 229개의 프로세스 ID 지원 (64-비트 전용, 32-비트 아키텍처는 여전히 215개로 제한), 장치 유형 수와 각 유형의 장치 수를 크게 늘림, 64-비트 지원 개선, 최대 16 테라바이트의 파일 크기를 지원하는 파일 시스템에 대해 지원, 커널-내 선점, 네이티브 POSIX 쓰레드 라이브러리 (NPTL)에 대해 지원, 메인라인 커널 소스에 사용자-모드 리눅스 통합, 메인라인 커널 소스에 SELinux 통합, InfiniBand 지원, 등이 있습니다.

2.6.x 릴리스부터, 커널은 많은 수의 파일 시스템을 지원했습니다; 그 중에는 ext3, ext4, FUSE, Btrfs와 같이 리눅스에 대해 설계된 것도 있고, JFS, XFS, Minix, Xenix, Irix, Solaris, System V, Windows, 및 MS-DOS와 같이 다른 운영 시스템에 기본으로 제공되는 것도 있습니다.

개발은 지금까지 버전 제어 시스템을 사용하지 않았지만, 2002년에, 리눅스 개발자들은 BitKeeper를 채택했으며, 이는 무료 소프트웨어는 아니었지만 자유롭게 사용할 수 있었습니다. 2005년에, 그것을 역-엔지니어링 시도로 인해, 소프트웨어를 소유한 회사는 리눅스 공동체에 대한 지원을 철회했습니다. 이에 대응하여, Torvalds와 다른 사람들은 Git을 작성했습니다. 새로운 시스템은 몇 주 만에 작성되었고, 2개월 만에 이를 사용하여 만든 첫 공식 커널이 출시되었습니다.

2005년에 안정 팀(stable team)은 커널 트리의 부족에 대한 응답으로 구성되었으며 여기서 사람들이 버그 수정 작업을 할 수 있고 안정적인 버전을 계속 업데이트했습니다. 2008년 2월에, linux-next 트리가 만들어져 다음 개발 주기 동안 병합될 패치를 모으는 장소 역할을 했습니다. 여러 하위-시스템 유지 관리자도 다음 릴리스 주기에 포함에 대한 제출을 의미하는 코드를 포함하는 트리에 대해 접미사 -next를 채택했습니다. 2014년 1월 기준, 개발 중인 리눅스 버전은 linux-next라는 불안정한 브랜치에 보관되어 있습니다.

리눅스의 20주년은 Torvalds에 의해 2011년 7월에 버전 3.0.0을 출시하면서 기념했습니다. 8년 동안 버전 번호가 2.6이었기 때문에, 3.x를 2.6.40+x로 보고하는 새로운 uname26 개성이 오래된 프로그램이 작동하도록 커널에 추가되어야 했습니다.

버전 3.0은 2011년 7월 22일에 출시되었습니다. 2011년 5월 30일에, Torvalds는 큰 변경 사항이 "아무것도 아닙니다. 정말 아무것도 아닙니다."라고 발표했고 "...다음 출시가 단순히 완전히 새로운 반짝이는 숫자가 아니라 좋은 커널이 되도록 합시다"라고 요청했습니다. 예상했던 6–7 주간의 개발 프로세스가 끝난 후 리눅스 20주년이 가까워지면 출시될 예정입니다.

2012년 12월 11일, Torvalds는 i386 프로세서에 대한 지원을 제거함으로써 커널 복잡성을 줄이기로 결정했습니다—특히 안정적인 뮤텍스를 허용하기 위해 i486과 함께 도입된 원자적 CMPXCHG 명령어를 에뮬레이션하지 않아도 됨으로써—커널 3.7 시리즈가 원래 프로세서를 계속 지원하는 마지막 시리즈가 되었습니다. 동일한 시리즈는 ARM 프로세서에 대한 지원을 통합했습니다.

2.6.39에서 3.0으로, 3.19에서 4.0으로의 번호 변경은 의미 있는 기술적 차별화를 수반하지 않았습니다; 주요 버전 번호는 단순히 큰 마이너 번호를 피하기 위해 증가했습니다. 안정적인 3.x.y 커널은 2015년 2월 3.19까지 출시되었습니다. 2013년 9월 2일에 출시된 버전 3.11은 임시 파일 취약성을 줄이기 위한 open(2)에 대한 새로운 O_TMPFILE 플래그, 실험적 AMD Radeon 동적 전원 관리, 저-지연 네트워크 폴링, 및 zswap (압축 스왑 캐시)과 같은 많은 새로운 기능을 추가했습니다.

2015년 4월, Torvalds는 커널 버전 4.0을 출시했습니다. 2015년 2월까지, 리눅스는 세계 최대 규모의 소프트웨어 및 하드웨어 공급업체를 포함하여 1,200개 이상의 회사에서 온 거의 12,000명의 프로그래머로부터 기여를 받았습니다. 2015년 6월에 출시된 리눅스 버전 4.1에는 거의 14,000명의 프로그래머가 기여한 1,950만 줄 이상의 코드가 포함되어 있습니다.

Linus Torvalds는 2019년 3월에 커널 버전 4.22가 대신 5.0으로 번호가 매겨질 것이라고 발표하면서 "'5.0'은 4.x 번호가 너무 커져서 내 손가락과 발가락이 다 떨어졌다는 것 이상을 의미하지 않는다"고 말했습니다. 그것은 AMD Radeon FreeSync 및 NVIDIA Xavier 디스플레이 지원, F2FS, EXT4, 및 XFS에 대한 수정, Btrfs 파일 시스템에서 스왑 파일에 대한 지원 복원과 Intel Icelake Gen11 그래픽 및 NXP i.MX8 SoC에 대한 작업 계속 등 많은 주요 추가 사항을 포함했습니다. 이 릴리스는 나머지 릴리스보다 눈에 띄게 컸으며, Torvalds는 "5.0 릴리스 전체에 대한 전반적인 변경 사항이 훨씬 더 크다"고 언급했습니다.

334명이 처음으로 협력한 개발자를 포함해 총 1,991명의 개발자가 버전 5.8에 553,000줄 이상의 코드를 추가하여 버전 4.9가 세웠던 기록을 깨뜨렸습니다.

Popularity

Stack Overflow의 2019년 연례 개발자 설문 조사에 따르면, 모든 응답자의 53% 이상이 리눅스에 대해 소프트웨어를 개발해 왔고 약 27%는 Android에 대해 개발해 왔지만, 리눅스-기반 운영 시스템으로 개발하는 사람은 약 25%에 불과합니다.

대부분의 웹사이트는 리눅스-기반 운영 시스템에서 실행되고, 세계의 가장 강력한 500대 수퍼컴퓨터 모두는 리눅스에서 실행됩니다.

리눅스 배포판은 커널과 함께 시스템 소프트웨어 (예를 들어, GNU C 라이브러리, systemd, 및 기타 유닉스 유틸리티와 데몬) 및 다양한 응용 프로그램 소프트웨어를 번들로 제공하지만, 다른 운영 시스템에 비해 데스크탑에서의 사용 점유율은 낮습니다.

리눅스인 Android는 모바일 기기 운영 시스템의 대부분을 차지하고 있고, 임베디드 기기에서의 사용이 증가로 인해, Android는 전반적인 리눅스 사용 증가에 큰 책임이 있습니다.

Value

전통적인 독점 개발 설정에서 리눅스 커널 버전 2.6.0을 재개발하기 위해 드는 비용은 COCOMO 인원-개월 추정 모델을 사용하여 2004년 가격으로 6억 1,200만 미국 달러 (4억 6,700만 유로, 3억 9,400만 파운드)로 추산되었습니다. 2006년, 유럽 연합에서 자금을 지원한 연구에서는 커널 버전 2.6.8의 재개발 비용을 8억 8,200만 유로 (11억 4,000만 달러, 7억 4,400만 파운드)로 더 높게 추산했습니다.

이 주제는 2008년 10월 Amanda McPherson, Brian Proffitt, 및 Ron Hale-Evans에 의해 다시 논의되었습니다. David A. Wheeler의 방법론을 사용하여, 그들은 2.6.25 커널 재개발 비용이 현재 13억 달러 (Fedora 9 재개발에 드는 총 108억 달러의 일부)라고 추정했습니다. 다시 한번, 스페인 오비에도 대학의 Garcia-Garcia와 Alonso de Magdaleno는 2005년과 2007년 사이에 커널에 매년 추가되는 가치가 약 1억 유로였고 2008년에는 2억 2,500만 유로였으며, 유럽 연합에서 개발하는 데도 10억 유로 (2010년 2월 기준 약 14억 달러) 이상이 소요될 것이라고 추정했습니다.

2011년 3월 7일 기준, 2.6.x 리눅스 커널의 당시 LOC (코드의 줄)와 David A. Wheeler의 계산에 따른 임금 수치와 함께 계속 커지는 리눅스 커널을 재개발하는 데 약 30억 달러 (약 22억 유로)가 소요됩니다. 4.14.14 리눅스 커널에 대해 당시 20,088,609 LOC (코드의 줄)와 현재 미국 프로그래머의 평균 급여 75,506달러를 사용하여 2018년 9월 26일 기준으로 업데이트된 계산에 따르면 기존 코드를 다시 작성하는 데 약 14,725,449,000달러 (11,191,341,000파운드)가 소요됩니다.

Distribution

리눅스를 사용하는 대부분의 사람들은 리눅스 배포판을 통해 그렇게 합니다. 일부 배포판은 vanilla 또는 stable 커널을 제공합니다. 어쨌든, 여러 공급업체 (예를 들어, Red Hat 및 Debian)는 사용자-지정 소스 트리를 유지 관리합니다. 이것들은 보통 vanilla 브랜치보다 느린 속도로 업데이트되고, 보통 관련 stable 브랜치에서 모든 수정 사항을 포함하지만, 동시에 배포판 공급업체가 브랜치를 기반으로 시작한 vanilla 버전에서 출시되지 않은 드라이버나 기능에 대한 지원을 추가할 수도 있습니다.

Developers

Community

리눅스 커널 개발자 공동체는 약 5000–6000명의 멤버로 구성되어 있습니다. Linux Foundation에 의해 발행된 "2017년 리눅스 커널 개발 현황"에 따르면, 릴리스 4.8~4.13에 대한 커밋을 다루는 연구에 따르면 평균적으로 약 1,500명의 개발자가 약 200–250개 회사에서 기여했습니다. 상위 30명의 개발자는 코드의 16%가 조금 넘는 기여를 했습니다. 회사에 대해, 상위 기여자는 Intel (13.1%)과 Red Hat (7.2%), Linaro (5.6%), IBM (4.1%)이고, 2위와 5위는 '없음' (8.2%)과 '알려지지 않음' (4.1%) 카테고리입니다.

로드맵 대신, 기술 가이드라인이 있습니다. 중앙 자원 할당 대신, 리눅스 커널의 추가 개발에 모두 이해 관계가 있는 개인과 회사가 있으며, 서로 상당히 독립적으로: Linus Torvalds와 저 같은 사람들은 커널 진화를 계획하지 않습니다. 우리는 앉아서 다음 2년 동안의 로드맵을 생각해내지 않고, 다양한 새로운 기능에 자원을 할당하지 않습니다. 그 이유는 우리는 어떤 자원도 가지고 있지 않기 때문입니다. 자원은 모두 리눅스를 사용하고 기여하는 다양한 기업과 다양한 독립적인 기여자가 소유하고 있습니다. 결정을 내리는 사람은 자원을 소유한 사람들입니다...

— Andrew Morton, 2005

Conflict

리눅스 커널 개발자들 사이의 주목할만한 갈등:

  • 2007년 7월, Con Kolivas는 리눅스 커널 개발을 중단하겠다고 발표했습니다.
  • 2009년 7월, Alan Cox는 Torvalds와의 의견 불일치로 인해 TTY 계층 유지 관리자 역할을 그만 두었습니다.
  • 2010년 12월, 리눅스 SCSI 유지 관리자 James Bottomley와 SCST 유지 관리자 Vladislav Bolkhovitin 사이에 리눅스 커널에 어떤 SCSI 대상 스택을 포함해야 하는지에 대한 논의가 있었습니다. 이것은 일부 리눅스 사용자를 화나게 만들었습니다.
  • 2012년 6월, Torvalds는 NVIDIA가 드라이버를 폐쇄형으로 출시하는 것에 동의하지 않는다는 점을 분명히 밝혔습니다.
  • 2014년 4월, Torvalds는 systemd가 커널과 부정적으로 상호 작용하도록 하는 버그를 처리하지 못했다는 이유로 리눅스 커널에 패치를 제출하는 것으로부터 Kay Sievers를 추방했습니다.
  • 2014년 10월, Lennart Poettering은 Torvalds가 리눅스 커널 관련 메일링 목록에서 거친 토론 스타일을 용인하고 나쁜 롤모델이 되고 있다고 비난했습니다.
  • 2015년 3월, Christoph Hellwig는 리눅스 커널의 저작권 침해로 VMware를 상대로 소송을 제기했습니다. Linus Torvalds는 변호사들을 곪아있는 질병이라고 불렀고 이와 유사한 이니셔티브에 동의하지 않는다는 것을 분명히 했습니다.
  • 2021년 4월, 미네소타 대학의 한 팀이 연구의 일환으로 커널에 "악의적인" 패치를 제출한 것으로 밝혀졌습니다. 이로 인해 대학 구성원이 제출한 모든 패치가 즉시 되돌려졌습니다. 게다가, 선임 유지 관리자가 대학의 향후 패치는 발견 즉시 거부될 것이라고 경고했습니다.

저명한 리눅스 커널 개발자는 개발자 사이의 갈등을 피하는 것이 중요하다는 사실을 알고 있습니다. Torvalds의 반대 때문에 오랫동안 커널 개발자를 위한 행동 강령이 없었습니다. 어쨌든, 리눅스 커널 갈등 강령이 2015년 3월 8일에 도입되었습니다. 그것은 2018년 9월 16일에 기여자 언약을 기반으로 한 새로운 행동 강령으로 대체되었습니다. 이것은 Torvalds에 의한 공개 사과와 커널 개발에서의 일시적인 휴식과 일치했습니다. 2018년 11월 30일에, Code of Conduct을 준수하여, Intel의 Jarkko Sakkinen은 소스 코드 주석에 나타나는 "fuck" 인스턴스를 "hug"라는 단어에 초점을 맞춘 적절한 버전으로 대체하는 패치를 보냈습니다.

불공평하게 대우받았다고 느끼는 개발자는 Linux Foundation 기술 자문 위원회에 이를 보고할 수 있습니다. 2013년 7월, USB 3.0 드라이버의 유지 관리자 Sage Sharp는 Torvalds에게 커널 개발 커뮤니티의 모욕적인 논평에 대해 언급해 달라고 요청했습니다. 2014년, Sharp는 리눅스 커널 개발에서 물러나며, "기술적 우수성에 초점을 맞추고, 과부하된 유지 관리자와 다른 문화적, 사회적 규범을 가진 사람들이 결합되어 리눅스 커널 유지 관리자는 종종 직설적이거나 무례하거나 잔인하게 일을 처리합니다"라고 말합니다. 2018년 linux.conf.au (LCA) 컨퍼런스에서 개발자들은 커뮤니티 문화가 지난 몇 년 동안 훨씬 좋아졌다는 견해를 표명했습니다. 인텔 drm/i915 그래픽 커널 드라이버의 유지 관리자, Daniel Vetter는 커널 커뮤니티에서 "다소 폭력적인 언어와 토론"이 줄어들거나 사라졌다고 언급했습니다.

Laurent Pinchart는 2017 Embedded Linux Conference Europe에서 개발자에게 커널 커뮤니티에서의 경험에 대한 피드백을 요청했습니다. 제기된 문제는 며칠 후 Maintainers Summit에서 논의되었습니다. 개발자가 제출한 패치에 대한 유지 관리자의 대응 방식에 일관성이 없다는 우려는 커널 자체 테스트 프레임워크의 유지 관리자, Shuah Khan에 의해 공감되었습니다. Torvalds는 시간이 지남에 따라 다른 커널 하위 시스템이 다른 개발 프로세스를 채택했기 때문에 패치 처리에 일관성이 없을 것이라고 주장했습니다. 그러므로, 각 커널 하위 시스템 유지 관리자가 패치 수용 규칙을 문서화하기로 합의했습니다.

Development

리눅스는 진화이지 지능적 설계가 아닙니다!

— Linus Torvalds, 2005

Codebase

커널 소스 코드, 일명 소스 트리는 Torvalds에 의해 만들어진 Git 버전 제어 시스템에서 관리됩니다.

2021년 기준, 리눅스 커널 5.11 릴리스에는 약 3,034만 줄의 코드가 있습니다. 코드의 약 14%는 아키텍처-별 코드, 커널 코드, 및 메모리 관리 코드를 포함한 "코어"의 일부이고, 60%는 드라이버입니다.

Contributions

기여는 리눅스 커널 메일링 리스트 (LKML) (그리고 종종 특정 하위 시스템에 전념하는 다른 메일링 리스트)에 텍스트 메시지 형태로 패치로 제출됩니다. 패치는 일련의 규칙과 형식 언어를 준수해야 하며, 다른 중에서도, 삭제될 코드 줄과 지정된 파일에 추가될 다른 줄이 무엇인지 설명하는 것을 포함합니다. 이들 패치는 시스템 관리자가 코드를 약간 변경하거나 다음 버전으로 점진적으로 업그레이드하기 위해 적용할 수 있도록 자동으로 처리될 수 있습니다. 리눅스는 GNU zip (gzip) 및 bzip2 형식으로도 배포됩니다.

리눅스 커널을 변경하기를 원하는 개발자는 코드 변경을 작성하고 테스트합니다. 변경의 중요성과 그것이 수정하는 하위 시스템의 수에 따라, 변경 사항은 소스 코드의 단일 패치 또는 여러 패치로 제출될 것입니다. 단일 유지 관리자에 의해 유지 관리되는 단일 하위 시스템의 경우에서, 이들 패치는 CC에서 적절한 메일링 목록을 갖는 하위 시스템의 유지 관리자에게 이메일로 전송됩니다. 유지 관리자와 메일링 목록의 독자는 패치를 검토하고 피드백을 제공할 것입니다. 일단 검토 프로세스가 완료되면 하위 시스템 유지 관리자가 관련 Git 커널 트리에서 패치를 수락합니다. 만약 리눅스 커널에 대한 변경 사항이 충분히 중요한 것으로 고려되는 버그 수정이면, 패치에 대한 풀 요청이 며칠 내에 Torvalds로 전송됩니다. 그렇지 않으면, 다음 병합 기간 동안 Torvalds로 풀 요청이 전송됩니다. 병합 기간은 보통 2주 동안 지속되고 이전 커널 버전의 출시 직후에 시작됩니다. Git 커널 소스 트리는 리눅스 커널에 기여한 모든 개발자를 Credits 디렉토리에 나열하고 모든 하위 시스템 유지 관리자는 Maintainers에 나열합니다.

많은 대규모 오픈-소스 소프트웨어 프로젝트에서와 마찬가지로, 개발자는 소수 기여자에 대한 괴롭힘을 해결하기 위한 행동 강령, 기여자 언약을 준수해야 합니다. 추가적으로, 불쾌감을 방지하기 위해 소스 코드 내에서 포괄적인 용어의 사용이 의무화되어 있습니다.

Programming language

리눅스는 GCC에 의해 지원되는 특수한 C 프로그래밍 언어로 작성됩니다. GCC는 대상 아키텍처의 어셈블리 언어 (GCC의 "AT&T 스타일" 구문)로 작성된 코드의 인라인 섹션을 사용하는 등 여러 가지 방법으로 C 표준을 확장하는 컴파일러입니다.

2021년 9월, 리눅스 커널을 컴파일하고 빌드하기 위한 GCC 버전 요구 사항이 GCC 4.9에서 5.1로 증가하여, 커널을 C89 표준을 기반으로 하는 C 코드에서 C11 표준으로 작성된 코드로 전환할 가능성이 생겼으며, 이 표준으로의 마이그레이션은 2022년 3월 리눅스 5.18이 출시되면서 이루어집니다.

Rust 프로그래밍 언어에 대한 초기 지원은 2022년 12월에 출시된 Linux 6.1에 추가되었으며, 리눅스 6.2 및 리눅스 6.3과 같은 이후 커널 버전에서는 지원이 더욱 향상되었습니다.

Coding style

2002년부터, 코드는 리눅스 커널 코딩 스타일을 구성하는 21개 규칙을 준수해야 합니다.

Versioning

대부분 소프트웨어와 마찬가지로, 커널은 점으로 구분된 일련의 숫자로 버전을 지정합니다.

초기 버전에 대해, 버전은 주요 릴리스, 보조 릴리스, 및 개정이라고 하는 3개 또는 4개의 점으로 구분된 숫자로 구성되었습니다.   당시, 홀수-번호의 보조 릴리스는 개발과 테스트용이었고, 짝수 번호의 보조 릴리스는 프로덕션용이었습니다. 선택 사항인 네 번째 숫자는 패치 수준을 나타냅니다. 개발 릴리스는 릴리스 후보 접미사 (-rc)로 표시되었습니다.

현재 버전 관리 규칙은 다릅니다. dev/prod를 의미하는 홀수/짝수가 버려졌고, 주요 버전은 처음 두 숫자를 함께 사용하여 표시됩니다. 다음 주요 버전을 개발할 수 있는 시간-프레임이 열려 있는 동안, -rcN 접미사는 다음 버전의 n-번째 릴리스 후보를 식별하기 위해 사용됩니다. 예를 들어, 버전 4.16이 릴리스되기 전에 7개의 4.16-rcN (-rc1에서 -rc7까지)이 사용되었습니다. 한번 안정적인 버전이 릴리스되면, 해당 유지 관리가 안정 팀으로 전달됩니다. 안정적인 릴리스에 대한 업데이트는 3개 숫자 체계 (예를 들어, 4.16.1, 4.16.2, ...)로 식별됩니다.

Toolchain

커널은 보통 GNU 툴체인으로 빌드됩니다. GNU C 컴파일러, GNU cc는 GNU 컴파일러 컬렉션 (GCC)의 일부로, 메인라인 리눅스에 대해 기본 컴파일러입니다. 시퀀싱은 GNU make에 의해 처리합니다. GNU 어셈블러 (종종 GAS 또는 GNU as라고 함)는 GCC에서 생성된 어셈블리 코드에서 개체 파일을 출력합니다. 마지막으로, GNU 링커 (GNU ld)는 vmlinux라는 정적으로 링크된 실행 가능한 커널 파일을 생성합니다. as와 ld는 모두 GNU 바이너리 유틸리티 (binutils)의 일부입니다.

GNU cc는 오랫동안 리눅스를 올바르게 빌드할 수 있는 유일한 컴파일러였습니다. 2004년에, Intel은 그들의 C 컴파일러도 커널을 컴파일할 수 있도록 커널을 수정했다고 주장했습니다. 2009년에 수정된 2.6.22 버전으로 이와 유사한 성공 사례가 또 보고되었습니다. Intel 컴파일러에 대한 지원은 2023년에 중단되었습니다.

2010년부터, C 언어에 대해 대안적인 컴파일러, Clang으로 리눅스를 빌드하려는 노력이 진행되어 왔습니다; 2014년 4월 12일 기준, 공식 커널은 Clang에 의해 거의 컴파일될 수 있습니다. 이 노력에 전념하는 프로젝트는 Clang이 빌드된 LLVM 컴파일러 인프라의 이름을 따서 LLVMLinux로 지어졌습니다. LLVMLinux는 리눅스나 LLVM을 포크하는 것을 목표로 하지 않았으며, 따라서 결국 업스트림 프로젝트에 제출되는 패치로 구성된 메타-프로젝트입니다. 리눅스가 Clang에 의해 컴파일되도록 활성화함으로써, 개발자는 컴파일 시간이 단축되는 이점을 얻을 수 있습니다.

2017년에, 개발자들은 4.15 릴리스에서 Clang으로 리눅스 커널을 빌드하는 것을 지원하기 위한 업스트리밍 패치를 완료했으며, 안정 커널 트리의 4.4, 4.9, 및 4.14 분기에 X86-64와 AArch64에 대한 지원을 백포트했습니다. Google의 Pixel 2는 최초의 Clang 빌드 리눅스 커널과 함께 제공되었지만, Pixel (1세대)에 대해 패치는 존재했습니다. 2018년에는 ChromeOS가 기본적으로 Clang으로 커널을 빌드하는 방식으로 전환했고, Android는 2019년에 Clang과 LLVM의 링커 LLD를 커널 빌드에 필수로 만들었습니다. Google은 2020년에 데이터센터 전체에서 사용되는 프로덕션 커널을 Clang으로 빌드하도록 전환했습니다. 오늘날 ClangBuiltLinux 그룹은 LLVMLinux로부터 구성원으로 구성되고 LLVMLinux로부터 업스트림 패치를 사용하여 호환성을 보장하기 위해 Linux와 LLVM에 대한 수정 사항을 조정합니다.

Debugging

임의의 소프트웨어와 마찬가지로, 리눅스 커널의 문제는 해결하기 어려울 수 있습니다. 공통적인 문제는 사용자-공간 대 커널-공간 접근, 동기화 원시 요소의 오용, 및 잘못된 하드웨어 관리와 관련이 있습니다.

oops는 커널의 치명적이지 않은 오류입니다. 그러한 오류 후에, 연산은 의심스러운 안정성으로 계속됩니다.

패닉 (panic()에 의해 생성됨)은 치명적인 오류입니다. 그러한 오류 후, 커널은 메시지를 인쇄하고 컴퓨터를 중지합니다.

커널은 순환 버퍼에 메시지를 저장하는 printk()를 통해 인쇄함으로써 디버깅을 제공합니다 (이전 엔트리를 새 것으로 덮어씁니다). syslog(2) 시스템 호출은 메시지 버퍼를 읽고 지우는 데 제공하고 콘솔에 보낼 메시지의 최대 로그 수준에 대해 제공할 수 있습니다. 커널 메시지는 /dev/kmsg 인터페이스를 통해 사용자 영역으로 내보내집니다.

ftrace 메커니즘은 추적함으로써 디버깅을 허용합니다. 그것은 런타임에 리눅스를 모니터링하고 디버깅하는 데 사용되고 커널 오작동으로 인한 사용자 공간 대기 시간을 분석할 수 있습니다. 더욱이, ftrace는 사용자에게 부팅 시 리눅스를 추적하도록 허용합니다.

kprobes와 kretprobes는 커널 실행 (사용자 공간에서 디버거와 유사)에 침입하고 중단 없이 정보를 수집할 수 있습니다. kprobes는 (거의) 임의의 주소의 코드에 삽입될 수 있고, 반면에 kretprobes는 함수 반환에서 작동합니다. uprobes는 유사한 목적을 가지고 있지만 그것들은 사용법과 구현에 약간의 차이점이 있습니다.

KGDB와 함께 리눅스는 사용자 공간 프로그램과 거의 같은 방식으로 디버깅될 수 있습니다. KGDB는 GDB를 실행하고 직렬 케이블이나 이더넷을 사용하여 디버깅될 대상에 연결된 추가 기계르 요구합니다.

Change process

리눅스 커널 프로젝트는 새로운 코드를 롤링 방식으로 통합합니다. 표준 운영 절차는 프로젝트에 체크인된 소프트웨어가 오류 없이 작동하고 컴파일되어야 한다는 것입니다.

각 커널 하위 시스템에는 패치를 커널 코드 표준에 따라 검토하고 보통 몇 주가 걸리는 병합 기간 내에 Torvalds에게 제출될 수 있는 패치 대기열을 유지하는 데 책임이 있는 유지 관리자가 지정됩니다.

패치는 Torvalds에 의해 이전 안정 리눅스 커널 릴리스의 소스 코드에 병합되어, 다음 안정 릴리스에 대한 릴리스 후보 (-rc)를 만듭니다. 일단 병합 창이 닫히면, 개발 릴리스에서 새 코드에 대한 수정 사항만 수락됩니다. 커널의 -rc 개발 릴리스는 회귀 테스트를 거치고 일단 Torvalds와 하위 시스템 유지 관리자에 의해 안정적이라고 고려되면, 새 버전이 릴리스되고 개발 프로세스가 다시 시작됩니다.

Mainline Linux

리눅스 커널 소스 코드를 포함하는 Git 트리는 메인라인 리눅스라고 참조됩니다. 모든 각 안정 커널 릴리스는 메인라인 트리에서 시작되고, kernel.org에 자주 게시됩니다. 메인라인 리눅스는 리눅스를 실행하는 많은 장치 중 작은 부분집합에 대해서만 견고한 지원을 제공합니다. 비-메인라인 지원은 Yocto나 Linaro와 같은 독립 프로젝트에 의해 제공되지만, 많은 경우에서 장치 공급업체로부터 커널이 필요합니다. 공급업체 커널을 사용하는 것은 보드 지원 패키지가 필요할 가능성이 높습니다.

메인라인 리눅스 외부에서 커널 트리를 유지 관리하는 것은 어려운 것으로 입증되어 왔습니다.

메인라이닝은 메인라인 커널에 장치 지원을 추가하는 작업을 참조하지만, 이전에는 포크에서만 지원하거나 전혀 지원하지 않았습니다. 이것은 보통 드라이버나 장치 트리 파일을 추가하는 것을 포함합니다. 이것이 완료될 때, 기능이나 보안 수정 사항이 메인라인된 것으로 고려됩니다.

Linux-like kernel

안정 브랜치의 유지 관리자, Greg Kroah-Hartman은 수백만 줄의 코드를 메인라인 커널에 추가하는 공급업체의 다운스트림 커널 포크에 리눅스-계열(Linux-like)이라는 용어를 적용했습니다. 2019년에, Google은 커널 포크의 수를 줄이기 위해 Android에서 메인라인 리눅스 커널을 사용하고 싶다고 밝혔습니다. 리눅스-계열이라는 용어는 전체 메인라인 리눅스 커널이 아니라 코드의 작은 수정된 부분-집합을 포함하는 Embeddable Linux Kernel Subset에도 적용되어 왔습니다.

Linux forks

공식 리눅스를 기반으로 커널을 개발하는 특정 커뮤니티가 있습니다. Linux-libre, Compute Node Linux, INK, L4Linux, RTLinux, 및 User-Mode Linux (UML)를 포함한 이들 포크의 흥미로운 코드 일부가 메인라인에 병합되어 왔습니다. 모바일 폰에 대해 개발된 일부 운영 시스템은 원래 Google Android, Firefox OS, HP webOS, Nokia Maemo, 및 Jolla Sailfish OS를 포함하여 리눅스의 대폭 수정된 버전을 사용했습니다. 2010년에, 리눅스 커뮤니티는 Google이 자체 커널 트리를 효과적으로 시작한 것에 대해 비판했습니다:

이것이 Android 하드웨어 플랫폼에 대해 작성된 임의의 드라이버는, Google의 커널 트리에만 있는 코드에 대한 종속성을 가지기 때문에 메인 커널 트리에 병합될 수 없으며, kernel.org 트리에서 빌드되지 않을 것이라는 의미입니다. 이것 때문에, Google은 이제 많은 양의 하드웨어 드라이버와 플랫폼 코드가 메인 커널 트리에 병합되는 것을 방지했습니다. 사실상 여러 공급업체가 현재 의존하고 있는 커널 브랜치를 만든 것입니다.

— Greg Kroah-Hartman, 2010

오늘날 안드로이드는 주요 변경 사항이 장치 드라이버에 구현된 맞춤형 리눅스를 사용하지만, 핵심 커널 코드에 대한 일부 변경 사항이 필요합니다. 안드로이드 개발자는 역시 공식 리눅스에 패치를 제출하여 마침내 안드로이드 운영 시스템을 부팅할 수 있습니다. 예를 들어, Nexus 7은 메인라인 리눅스를 부팅하고 실행할 수 있습니다.

2001년 컴퓨터 역사 박물관에서 열린 프레젠테이션에서, Torvalds는 리눅스 배포판이 정확히 같은 커널 소스를 사용하는지 여부에 대한 질문에 다음과 같이 답했습니다:

그것들은 그렇지 않습니다... 글쎄요, 그런 것도 있고, 아닌 것도 있습니다. 단일 커널은 없습니다. 모든 각 단일 배포판은 자체 변경 사항을 가지고 있습니다. 그것은 거의 첫날부터 계속되어 왔습니다. 기억하실지 모르겠지만, Yggdrasil은 커널에 꽤 극단적인 변경 사항을 가한 것으로 알려졌고 오늘날에도 모든 주요 공급업체는 관심 있는 시장의 일부가 있기 때문에 자체적인 변경 사항을 적용하고 있고, 솔직히 말해서 그것이 커널이 있어야 할 방식입니다. 모든 사람이 한 사람, 즉, 나만이 모든 것을 추적할 수 있기를 기대한다면, 그것이 GPL의 요점이 아닙니다. 그것이 오픈 시스템의 요점이 아닙니다. 따라서 사실 배포판에서 무언가가 너무 중요해서 표준 커널에 없더라도 패치를 추가할 것이라고 결정한다는 사실은 저에게 정말 좋은 신호입니다. 그래서 예를 들어 ReiserFS와 같은 것이 추가된 방식입니다. 그리고 ReiserFS가 표준 커널에 통합된 최초의 저널링 파일 시스템이 된 이유는 제가 Hans Reiser를 좋아해서가 아니었습니다. 그것은 SUSE가 실제로 그들의 표준 커널로 ReiserFS를 제공하기 시작했기 때문에 "좋아요"라고 말했기 때문입니다. 이것은 실제로 프로덕션에서 사용됩니다. 보통 사람들은 이렇게 합니다. 그들은 제가 모르는 무언가를 알고 있을 것입니다. 그래서 매우 현실적인 의미에서 많은 배포판 하우스가 하는 일은 "우리만의 브랜치를 만들자"와 "여기에 변경 사항을 적용하자"의 일부입니다. 그리고 GPL 덕분에, 저는 그중에서 가장 좋은 부분을 가져갈 수 있습니다.

— Linus Torvalds, 2001

Long-term support

최신 버전과 이전 버전은 별도로 유지 관리됩니다. 최신 커널 릴리스의 대부분은 Torvalds에 의해 감독되었습니다.

리눅스 커널 개발자 커뮤니티는 후속 안정적 커널 개발 중에 발견된 소프트웨어 버그에 대한 수정 사항을 적용함으로써 안정적 커널을 유지합니다. 그러므로, www.kernel.org는 항상 두 개의 안정적 커널을 나열합니다. 다음 안정 리눅스 커널은 약 8~12주 후에 출시됩니다.

일부 릴리스는 2년 이상 버그 수정 릴리스와 함께 longterm으로 장기 지원을 위해 지정됩니다.

Size

일부 프로젝트는 리눅스 커널의 크기를 줄이려고 시도해 왔습니다. 그 중 하나가 TinyLinux입니다. 2014년에, Josh Triplett은 축소된 크기의 버전을 위한 -tiny 소스 트리를 시작했습니다.

Architecture and features

비록 모순되는 것처럼 보이지만, 리눅스 커널은 모놀리식이고 모듈러입니다. 커널은 전체 OS가 커널 공간에서 실행되기 때문에 구조적으로 모놀리식 커널로 분류됩니다. 설계는 모듈러인데 왜냐하면 그것은 어떤 경우에는 런타임에 로드되고 언로드되는 모듈에서 조립될 수 있기 때문입니다. 그것은 비-자유 운영 시스템의 폐쇄 소스 커널에서만 사용할 수 있었던 기능을 지원합니다.

기사의 남은 부분은 유닉스와 유닉스-계열 운영 시스템의 매뉴얼 페이지의 규칙을 사용합니다. 명령, 인터페이스, 또는 기타 기능의 이름 뒤에 오는 숫자는 그것의 속하는 섹션 (즉, OS 구성 요소 또는 기능의 유형)을 지정합니다. 예를 들어, execve(2)는 시스템 호출을 참조하고, exec(3)은 사용자-공간 라이브러리 래퍼를 참조합니다.

다음은 아키텍처 설계의 개요와 주목할 만한 특징입니다.

  • SMP 및 NUMA 아키텍처에서 동시 컴퓨팅과 (실행할 준비가 된 작업에 충분한 CPU 코어를 사용할 수 있는 경우) 심지어 한 번에 여러 프로세스의 진정한 병렬 실행 (각 프로세스에는 하나 이상의 실행 스레드가 있음).
  • 수백 개의 커널 기능과 드라이버의 선택과 구성 (빌드하기 전에 make *config 명령 계열 중 하나를 사용), 부팅 전에 커널 매개변수 수정 (보통 GRUB2 메뉴 줄에 명령어 삽입함으로써), 및 런타임 시 커널 동작 미세 조정 (/proc/sys/에 대한 sysctl(8) 인터페이스 사용).
  • 구성 (다시 make *config 명령 사용) 및 선점형 멀티태스킹 (사용자 모드와 2.6 시리즈 이후 커널 모드 모두)을 허용하는 작업 스케줄러의 정책 (nice(2), setpriority(2), 및 sched_*(2) 시스템-호출 가족을 통해)의 런-타임 수정; 가장 빠른 적격 가상 마감일 우선 스케줄링 (EEVDF) 스케줄러는, 2023년 이후 리눅스의 기본 스케줄러이고 그것은 O(log n) 시간 복잡도를 갖는 프로세스 정보 (작업 구조체)를 검색, 삽입, 및 삭제할 수 있는 레드-블랙 트리를 사용하며, 여기서 n은 실행 가능한 작업의 수입니다.
  • 페이지 가상 메모리를 갖는 고급 메모리 관리.
  • 프로세스-사이 통신 및 동기화 메커니즘.
  • 여러 실제 파일 시스템 (ext4, Btrfs, XFS, JFS, FAT32, 등) 위에 구축된 가상 파일-시스템.
  • 구성 가능한 I/O 스케줄러, 특수 파일의 놓여있는 장치 매개변수를 조작하는 ioctl(2) 시스템-호출 (그것은 비-표준 시스템 호출인데, 왜냐하면 인수, 반환, 및 의미 체계가 질문에서 장치 드라이버에 의존하기 때문), POSIX 비동기 I/O에 대해 지원 (어쨌든, 그것들은 멀티스레드 응용 프로그램과 함께 확장성이 낮기 때문에, 리눅스 특정 I/O 시스템 호출 (io_*(2)) 가족은 동시 처리에 적합한 비동기 I/O 컨텍스트의 관리를 위해 만들어져야 합니다).
  • OS-수준 가상화 (Linux-VServer와 함께), 준가상화 및 하드웨어-지원 가상화hard (KVM 또는 Xen과 함께, 그리고 하드웨어 에뮬레이션을 위한 QEMU을 사용); Xen 하이퍼바이저에서, 리눅스 커널은 사용자의 가상 기계 (DomU)에 대한 관리 환경을 제공하는 가상 기계 호스트 서버인 Dom0로 작동하는 리눅스 배포판 (예를 들어, openSUSE Leap 및 기타 여러 버전)을 빌드하기 위한 지원을 제공합니다.
  • VFIO 및 SR-IOV를 갖는 I/O 가상화. Virtual Function I/O (VFIO)는 보안 메모리 (IOMMU) 보호 환경에서 사용자 공간에 대한 직접 장치 접근을 노출합니다. VFIO와 함께, VM 게스트가 VM 호스트 서버의 하드웨어 장치에 직접 접근할 수 있습니다. 이 기술은 만약 완전한 가상화 및 준가상화와 비교되면 성능을 향상시킵니다. 어쨌든, VFIO와 함께, 장치는 여러 VM 게스트와 공유될 수 없습니다. Single Root I/O Virtualization (SR-IOV)는 VFIO의 성능 향상과 여러 VM 게스트와 장치를 공유하는 기능을 결합합니다 (그러나 그것은 두 개 이상의 VM 게스트에게 다른 장치로 표시될 수 있어야 하는 특수 하드웨어를 요구합니다).
  • 임의 및 필수 접근 제어를 위한 보안 메커니즘 (SELinux, AppArmor, POSIX ACL, 및 기타).
  • 여러 유형의 계층화된 통신 프로토콜 (인터넷 프로토콜 모음 포함)
  • RPMsg 하위-시스템을 통한 비대칭 멀티프로세싱.

대부분의 장치 드라이버와 커널 확장은 하드웨어에 대한 전체 접근 권한을 갖는 커널 공간 (많은 CPU 아키텍처의 링 0)에서 실행됩니다. 일부 예외는 사용자 공간에서 실행됩니다; 주목할 만한 예로는 FUSE/CUSE 기반 파일 시스템과 UIO의 일부가 있습니다. 더욱이, 대부분의 사람들이 리눅스에서 사용하는 윈도잉 시스템 및 디스플레이 서버 프로토콜, X Window System과 Wayland는 커널 내에서 실행되지 않습니다. 다르게, 그래픽 카드의 GPU와의 실제 인터페이싱은 Direct Rendering Manager (DRM)라는 커널 내 하위-시스템입니다.

표준 모놀리식 커널과 달리, 장치 드라이버는 모듈로 쉽게 구성되고, 시스템이 실행되는 동안 로드되거나 언로드되고 하드웨어 인터럽트를 올바르게 처리하고 대칭적 멀티프로세싱을 더 잘 지원하기 위해 특정 조건에서 선점될 수도 있습니다. 선택에 의해, 리눅스는 안정적인 장치 드라이버 응용 프로그램 바이너리 인터페이스를 가지고 있지 않습니다.

리눅스는 전형적으로 메모리 보호 및 가상 메모리를 활용하고 비-균등 메모리 접근도 처리할 수 있으며, 어쨌든 이 프로젝트는 μClinux를 흡수하여 가상 메모리 없이 마이크로컨트롤러에서 리눅스를 실행할 수 있게 되었습니다.

하드웨어는 파일 계층 구조로 표현됩니다. 사용자 응용 프로그램은 /dev 또는 /sys 디렉토리의 엔트리를 통해 장치 드라이버와 상호 작용합니다. 프로세스 정보는 /proc 디렉토리에 매핑됩니다.

Interfaces

리눅스는 유닉스의 복제본으로 시작되었고, POSIX와 Single UNIX Specification 준수를 목표로 합니다. 커널은 리눅스에 특화된 시스템 호출과 기타 인터페이스를 제공합니다. 공식 커널에 포함되기 위해, 코드가 일련의 라이선스 규칙을 준수해야 합니다.

커널과 사용자 공간 사이의 리눅스 응용 프로그램 바이너리 인터페이스 (ABI)에는 4가지 안정성 수준 (안정, 테스팅, 폐기, 제거됨)이 있습니다; 시스템 호출은 그것들에 의존하는 사용자 공간 프로그램에 대해 호환성을 유지하기 위해 절대 변경되지 않을 것으로 예상됩니다.

로드 가능한 커널 모듈 (LKM)은, 설계에 의해, 안정적인 ABI에 의존할 수 없습니다. 그러므로, 그것들은 새로운 커널 실행 파일이 시스템에 설치될 때마다 항상 다시 컴파일되어야 하며, 그렇지 않으면 그것들은 로드되지 않을 것입니다. 커널 실행 파일 (vmlinux)의 필수 부분이 되도록 구성된 트리-내 드라이버는 빌드 프로세스에 의해 정적으로 링크됩니다.

소스-수준 커널 내부 API의 안정성의 보장은 없고, 이것 때문에, 장치 드라이버 코드와 마찬가지로 다른 커널 하위-시스템의 코드는 커널 진화에 따라 최신 상태로 유지되어야 합니다. API를 변경하는 임의의 개발자는 변경으로 인해 중단되는 임의의 코드를 수정해야 합니다.

Kernel-to-userspace API

사용자 응용 프로그램에 노출된 인터페이스와 관련된 리눅스 커널 API의 모음은 토대적으로 유닉스와 리눅스-특정 시스템 호출로 구성됩니다. 시스템 호출은 리눅스 커널에 대한 진입점입니다. 예를 들어, 리눅스-특정 시스템 호출 중에,  clone(2) 시스템 호출의 가족이 있습니다. 대부분의 확장은 헤더 파일에서 _GNU_SOURCE 매크로를 정의하거나 사용자-영역 코드가 컴파일될 때 활성화되어야 합니다.

시스템 호출은 링 0에서 권한-없는 사용자 공간으로부터 권한-있는 커널 공간으로의 전환을 활성화하는 어셈블리 명령어를 통해서만 호출될 수 있습니다. 이러한 이유로, C 표준 라이브러리 (libC)는, 필요하다면, 호출 프로세스를 대신하여 실행될 커널에 투명하게 들어가는 C 함수를 노출함으로써 대부분의 리눅스 시스템 호출에 대한 래퍼 역할을 합니다. 빠른 사용자-공간 뮤텍스와 같이 libC에 의해 노출되지 않는 시스템 호출에 대해, 라이브러리는 syscall(2)이라는 함수를 제공하며, 이는 명시적으로 그것들을 호출하기 위해 사용될 수 있습니다.

유사 파일-시스템 (예를 들어, sysfs와 procfs 파일-시스템)과 특수 파일 (예를 들어, /dev/random, /dev/sda, /dev/tty, 및 기타 여러 파일)은 하드웨어 또는 논리적 (소프트웨어) 장치를 나타내는 커널 데이터 구조에 대한 또 다른 인터페이스의 계층을 구성합니다.

Kernel-to-userspace ABI

Main article: Linux Standard Base

Linux OS의 수백 가지 다양한 구현 사이에 존재하는 차이점 때문에, 실행 가능한 객체은, 심지어 그것들이 특정 하드웨어 아키텍처에서 실행되도록 컴파일, 어셈블, 및 링크되었더라도 (즉, 그것들이 대상 하드웨어의 ISA를 사용함), 종종 다른 리눅스 배포판에서 실행할 수 없습니다. 이 문제는 주로 배포판-별 구성과 리눅스 커널 코드에 적용된 패치의 모음, 시스템 라이브러리, 서비스 (데몬), 파일 시스템 계층, 및 환경 변수의 차이로 인해 발생합니다.

리눅스 배포판의 응용 프로그램과 바이너리 호환성에 관한 주요 표준은 Linux Standard Base (LSB)입니다. 어쨌든, LSB는 리눅스 커널과 관련된 것 이상을 정의하는데, 왜냐하면 그것이 데스크탑 사양, X 라이브러리와 그것과 거의 관련이 없는 Qt도 정의하기 때문입니다. LSB 버전 5는 여러 표준과 초안 (POSIX, SUS, X/Open, 파일 시스템 계층 (FHS), 등)을 기반으로 구축되었습니다.

커널과 더욱 관련이 있는 LSB의 부분은 일반 ABI (gABI), 특히 System V ABI, 및 실행-가능 및 연결 형식 (ELF), 및 프로세서 특정 ABI (psABI), 예를 들어 X86-64에 대한 핵심 사양입니다.

x86_64 사용자 프로그램이 시스템 호출을 호출하는 방법에 대한 표준 ABI는 syscall 번호를 rax 레지스터에 로드하고, 다른 매개변수를 rdi, rsi, rdx, r10, r8, 및 r9에 로드하고, 마지막으로 syscall 어셈블리 명령어를 코드에 넣는 것입니다.

In-kernel API

커널 하위-시스템 사이에는 여러 개의 내부 커널 API가 있습니다. 일부는 커널 하위-시스템 내에서만 사용할 수 있고, 반면에 다소 제한적인 커널-내부 심볼의 모음 (예를 들어, 변수, 데이터 구조, 및 함수)은  그것들이 EXPORT_SYMBOL()과 EXPORT_SYMBOL_GPL() 매크로로 내보내는지 여부에 관계없이 동적으로 로드할 수 있는 모듈 (예를 들어, 요구에 따라 로드되는 장치 드라이버)에 노출됩니다 (EXPORT_SYMBOL_GPL()는 GPL 호환 라이선스에 따라 릴리스된 모듈에만 예약됩니다).

리눅스는 데이터 구조 (예를 들어, 연결 목록, 기수 트리, 빨강-검정 트리, 대기열)를 조작하거나 공통 루틴 (예를 들어, 사용자 공간에서 그리고 사용자 공간으로 데이터 복사, 메모리 할당, 시스템 로그에 줄 인쇄, 등)을 수행하는 커널 내 API를 제공하며 이는 최소한 리눅스 버전 2.6 이후로 안정적으로 유지되었습니다.

커널-내부 API에는 장치 드라이버에 의해 사용되는 저-수준 공통 서비스 라이브러리가 포함됩니다:

  • SCSI 인터페이스와 libATA – 각각 USB, SATA, SAS, Fibre Channel, FireWire, ATAPI 장치에 부착된 저장 장치를 위한 피어-투-피어 패킷 기반 통신 프로토콜, 및 [S]ATA 호스트 컨트롤러와 장치를 지원하는 커널 내부 라이브러리.
  • Direct Rendering Manager (DRM)와 Kernel Mode Setting (KMS) – GPU와 인터페이싱하고 최신 3D-가속 비디오 하드웨어의 요구 사항을 지원하고, 화면 해상도, 색상 깊이, 및 재생율을 설정하기 위해.
  • DMA 버퍼 (DMA-BUF) – 여러 장치 드라이버와 하위-시스템 사이의 하드웨어 직접 메모리 접근을 위한 버퍼 공유를 위해,
  • Video4Linux – 비디어 캡처 하드웨어를 위해
  • Advanced Linux Sound Architecture (ALSA) – 사운드 카드를 위해
  • New API – 네트워크 인터페이스 컨트롤러를 위해
  • mac80211와 cfg80211 – 무선 네트워크 인터페이스 컨트롤러를 위해,

In-kernel ABI

리눅스 개발자는 안정적인 커널-내 ABI를 유지하지 않기로 했습니다. 특정 버전의 커널에 대해 컴파일된 모듈은 재컴파일하지 않고는 다른 버전으로 로드될 수 없습니다.

Multiprocessing

리눅스는 clone(2) 또는 최신 clone3(2) 시스템 호출을 수단으로 프로세스를 생성합니다. 이들 시스템 호출은 새 독립 프로세스 (각각 커널 공간의 task_struct 데이터 구조 내에서 TGID라는 특수 식별자를 갖지만, 해당 같은 식별자는 사용자 공간에서 PID라고 함)부터 호출 프로세스 내의 새 스레드에 이르기까지 다양한 새 엔터티를 생성합니다.

만약 실행 파일이 공유 라이브러리에 동적으로 링크되면, 동적 링커는 필요한 객체를 찾아 로드하고 프로그램을 실행하도록 준비하고 그런-다음 그것을 실행하도록 사용됩니다.

네이티브 POSIX 스레드 라이브러리 (NPTL)는 사용자-공간에 POSIX 표준 스레드 인터페이스 (pthreads)를 제공합니다.

커널은 사용자 공간 잠금 및 동기화를 위한 futex(7) (빠른 사용자-공간 뮤텍스) 메커니즘을 제공합니다.ㅍ 대부분의 연산은 사용자-공간에서 수행되지만 그것은 futex(2) 시스템 호출을 사용하여 커널과 통신해야 할 수 있습니다.

위에서 설명된 사용자 공간 스레드와 달리, 커널 스레드는 커널 공간에서 실행됩니다.

Scheduling

리눅스 프로세스 스케줄러는, 그것이 다양한 스케줄링 클래스와 정책을 활성화한다는 의미에서 모듈러입니다. 스케줄러 클래스는 기본 스케줄러 코드에 등록될 수 있는 플러그-가능한 스케줄러 알고리즘입니다. 각 클래스는 다양한 유형의 프로세스를 스케줄링합니다. 스케줄러의 핵심 코드는 우선순위에 따라 각 클래스를 반복하고 실행할 준비가 된 struct sched_entity 유형의 스케줄링-가능한 엔터티를 가지는 가장 높은 우선순위 스케줄러를 선택합니다.  엔터티는 스레드, 스레드 그룹, 및 심지어 특정 사용자의 모든 프로세스일 수 있습니다.

리눅스는 사용자 선점과 마찬가지로 완전한 커널 선점을 모두 제공합니다.  선점은 대기 시간을 줄이고, 응답성을 높이고, 리눅스를 데스크탑 및 실시간 응용 프로그램에 더 적합하게 만듭니다.

통상적인 작업에 대해, 기본적으로, 커널은 버전 2.6.23에서 도입된 Completely Fair Scheduler (CFS) 클래스를 사용합니다. 스케줄러는 C 헤더에서 SCHED_NORMAL이라는 매크로로 정의됩니다. 다른 POSIX 커널에서, SCHED_OTHER라고 알려진 유사한 정책이 CPU 시간-분할을 할당합니다 (즉, 그것은 각 프로세스의 미리 결정된 우선순위 또는 동적으로 계산된 우선순위에 따라 프로세서 시간의 절대 분할을 할당합니다). 리눅스 CFS는 절대 시간-분할을 없애고 실행-가능한 프로세스의 총 수와 이미 실행된 시간과 같은 매개변수의 함수로 CPU 시간의 공정한 비율을 할당합니다; 이 함수는 역시 상대적 우선순위 (nice 값)에 따라 달라지는 일종의 가중치도 고려합니다. 

사용자 선점과 함께, 커널 스케줄러는 현재 프로세스를 컨텍스트 스위치의 실행으로 대체하여 따라서 실행을 위한 컴퓨팅 자원 (CPU, 메모리, 등)을 획득할 수 있습니다. 그것은 CFS 알고리즘 (특히, 엔터티를 정렬하는 데 vruntime이라는 변수를 사용하고 그런-다음 더 작은 runtime을 가지는 엔터티 - 즉 CPU 시간을 가장 적게 차지한 스케줄링 가능한 엔터티를 선택함), 스케줄러 정책과 상대적 우선 순위에 따라 이를 수행합니다. 커널 선점과 함께, 커널은 인터럽트 핸들러가 반환될 때, 커널 작업이 차단될 때, 및 서브시스템이 schedule() 함수를 명시적으로 호출할 때마다 자체를 선점할 수 있습니다.

커널은 역시 SCHED_FIFO (실시간 선입선출) 및 SCHED_RR (실시간 라운드-로빈)이라는 두 개의 POSIX-호환 실시간 스케줄링 클래스도 포함하고 있으며, 둘 다 기본 클래스보다 우선합니다. 가장 빠른 마감일 우선 알고리즘 (EDF)을 구현하는 SCHED DEADLINE으로 알려진 추가적인 스케줄링 정책이 2014년 3월 30일에 출시된 커널 버전 3.14에 추가되었습니다. SCHED_DEADLINE은 모든 다른 스케줄링 클래스보다 우선합니다.

버전 2.6 이후 메인라인 리눅스에 포함된 실시간 PREEMPT_RT 패치는 결정론적 스케줄러, 선점 및 인터럽트 비활성화 제거 (가능한 경우), PI 뮤텍스 (즉, 우선순위 역전을 방지하는 잠금 기본), 고정밀 이벤트 타이머 (HPET), 선점형 읽기-복사-업데이트 (RCU), (강제) IRQ 스레드, 및 기타 사소한 기능에 대한 지원을 제공합니다.

2023년에, Peter Zijlstra는 CFS를 가장 빠른 적격 가상 마감일 우선 스케줄링 (EEVDF) 스케줄러로 교체하여, CFS "지연성 나이스" 패치가 필요 없도록 제안했습니다. EEVDF 스케줄러는 리눅스 커널 버전 6.6에서 CFS를 교체했습니다.

Synchronization

커널에는 동시성의 원인이 다양합니다 (예를 들어, 인터럽트, 바텀 하프, 커널 및 사용자 작업의 선점, 대칭적 멀티프로세싱). 

치명적 영역 (원자적으로 실행되어야 하는 코드의 섹션), 공유 메모리 위치 (전역 변수와 전역 범위가를 갖는 다른 데이터 구조, 등), 및 하드웨어에 의해 비동기적으로 수정될 수 있는 메모리의 영역 (예를 들어, C volatile 유형 한정자를 가짐)을 보호하기 위해, 리눅스는 다양한 도구의 모음을 제공합니다. 그것들은 원자 유형 (특정 연산자의 집합으로만 조작될 수 있음), 스핀록, 세마포어, 뮤텍스, 및 잠금-없는 알고리즘 (예를 들어, RCU)으로 구성됩니다. 대부분의 잠금-없는 알고리즘은 메모리 순서화를 강제하고 컴파일러 최적화로 인한 원치 않는 부작용을 방지하기 위해 메모리 장벽 위에 구축됩니다.

메인라인 리눅스에 포함된 PREEMPT_RT 코드는 선점을 비활성화하지 않고 우선순위 상속에 대해 지원을 가지는 특수한 종류의 뮤텍스, RT-뮤텍스를 제공합니다. 거의 모든 잠금은 실시간 연산을 위한 구성을 사용할 때 휴면 잠금으로 변경됩니다. 우선순위 상속은 해당 잠금이 해제될 때까지 경합 잠금을 보유한 낮은 우선순위 작업에 더 높은 우선순위 대기자의 우선순위를 부여함으로써 우선순위 역전을 방지합니다.

리눅스에는 Lockdep이라는 커널 잠금 검증기가 포함되어 있습니다.

Interrupts

비록 인터럽트의 관리가 단일 작업으로 볼 수 있지만, 그것은 두 개로 나뉩니다. 이렇게 두 개로 나뉜 것은 시간 제약이 다르고 관리가 구성되는 작업의 동기화 요구 사항 때문입니다. 첫 번째 부분은 리눅스에서 상단 절반이라고 알려진 비동기 인터럽트 서비스 루틴으로 구성되고, 반면에 두 번째 부분은 소위 하단 절반 (softirq, tasklets, 및 work queues)의 세 가지 유형 중 하나에 의해 수행됩니다. 

리눅스 인터럽트 서비스 루틴은 중첩될 수 있습니다. 새로운 IRQ는 다른 낮은 우선순위 ISR을 선점하는 높은 우선순위 ISR로 트랩될 수 있습니다.

Memory

리눅스는 5-수준 페이지 테이블로 가상 메모리를 구현합니다. 커널은 페이지-가능이 아니고 (페이지-가능은 항상 물리적 메모리에 상주하고 디스크로 스왑될 수 없음을 의미합니다), 메모리 보호 기능도 없고 (사용자 공간과 달리 SIGSEGV 신호 없음), 따라서 메모리 위반은 불안정성과 시스템 충돌로 이어집니다.   사용자 메모리는 기본적으로 페이지-가능이지만, 특정 메모리 영역에 대한 페이징은 mlock() 시스템 호출 가족과 함께 비활성화될 수 있습니다.

페이지 프레임 정보는 부팅 직후에 채워지고 그것들이 가상 페이지와 결합되어 있는지 여부와 관계없이 종료될 때까지 보관되는 (struct page 유형의) 적절한 데이터 구조에 유지됩니다. 물리적 주소 공간은 아키텍처 제약 및 의도된 용도에 따라 여러 영역으로 나뉩니다. 여러 메모리 뱅크를 갖는 NUMA 시스템도 지원됩니다.

작은 메모리 덩어리는 kmalloc() API 계열을 통해 커널 공간에서 동적으로 할당될 수 있고, 적절한 kfree() 변형을 통해 해제될 수 있습니다. vmalloc()과 kvfree()는 크고 사실상 연속된 덩어리에 사용됩니다. alloc_pages()는 원하는 수의 전체 페이지를 할당합니다.

커널은 구성 가능한 대안으로 SLAB, SLUB, 및 SLOB 할당자를 포함하곤 했습니다. SLOB 할당자는 리눅스 6.4에서 제거되었고, SLAB 할당자는 리눅스 6.8에서 제거되었습니다. 유일하게 남아 있는 할당자는 단순성과 효율성을 목표로 하는 SLUB이며, PREEMPT_RT와 호환되고 리눅스 2.6에서 도입되었습니다.

Supported architectures

원래 이식 가능하도록 설계되지는 않았지만, 리눅스는 현재 가장 광범위하게 이식된 운영 시스템 커널 중 하나로, ARM 아키텍처에서 IBM z/Architecture 메인프레임 컴퓨터에 이르기까지 다양한 시스템에서 실행됩니다. 첫 번째 이식은 Motorola 68000 플랫폼에서 수행되었습니다. 커널에 대한 수정 사항이 너무 근본적이어서 Torvalds는 Motorola 버전을 포크 및 "리눅스-계열 운영 시스템"으로 보았습니다. 어쨌든, 이로 인해 Torvalds는 더 많은 컴퓨팅 아키텍처로 이식하기 쉽도록 코드를 대대적으로 재구성했습니다. 단일 소스 트리에서 i386만을 위한 코드 이상을 가진 최초의 리눅스는 DEC Alpha AXP 64-비트 플랫폼을 지원했습니다.

리눅스는 IBM의 Summit의 주요 운영 시스템으로 실행됩니다; 2019년 10월 기준, 세계에서 가장 빠른 500대 수퍼컴퓨터는 모두 리눅스 커널을 기반으로 하는 운영 시스템을 실행하며, 이는 최초의 리눅스 수퍼컴퓨터가 목록에 추가된 1998년 이후로 큰 변화가 되었습니다.

리눅스는 Apple의 iPhone 3G 및 iPod와 같은 다양한 핸드헬드 기기에도 이식되어 왔습니다.

Supported devices

2007년에, LKDDb 프로젝트는 리눅스 커널에 의해 알려진 하드웨어와 프로토콜의 포괄적인 데이터베이스를 구축하기 위해 시작되어 왔습니다. 데이터베이스는 커널 소스의 정적 분석에 의해 자동으로 구축됩니다. 나중에 2014년에, 리눅스 하드웨어 프로젝트는 다양한 리눅스 배포판 사용자의 도움을 받아 테스트된 모든 하드웨어 구성의 데이터베이스를 자동으로 수집하기 위해 시작되었습니다.

Live patching

재부팅-없는 업데이트가 Ksplice, kpatch, 및 kGraft와 같은 라이브 패치 기술을 사용함으로써 커널에 적용될 수도 있습니다. 라이브 커널 패치를 위한 최소한의 기반은 2015년 4월 12일에 출시된 커널 버전 4.0에서 리눅스 커널 메인라인에 병합되었습니다. 라이브패치라고 알려져 있고 주로 커널의 ftrace 기능을 기반으로 하는 그것들의 토대는 핫 패치를 포함하는 커널 모듈에 대한 응용 프로그램 프로그래밍 인터페이스 (API)와 사용자-공간 관리 유틸리티에 대한 응용 프로그램 바이너리 인터페이스 (ABI)를 제공함으로써 kGraft와 kpatch 모두에 의해 핫 패치를 지원할 수 있는 공통 코어를 형성합니다. 어쨌든, 리눅스 커널 4.0에 포함된 공통 코어는 x86 아키텍처만 지원하고 핫 패치가 적용되는 동안 함수-수준의 일관성을 보장하는 메커니즘을 제공하지 않습니다. 2015년 4월 기준, 리눅스 커널 메인라인에 의해 제공되는 공통 라이브 패치 코어로 kpatch와 kGraft를 이식하는 작업이 진행 중입니다.

Security

커널 버그는 잠재적인 보안 문제를 야기합니다. 예를 들어, 그것들은 권한 상승을 허용하거나 서비스-거부 공경 벡터를 생성할 수 있습니다. 수년에 걸쳐, 시스템 보안에 영향을 미치는 수많은 버그가 발견되고 수정되었습니다. 새로운 기능이 커널의 보안을 개선하기 위해 자주 구현됩니다.

Capabilities(7)는 프로세스 및 스레드에 대한 섹션에서 이미 소개되었습니다. Android는 이를 활용하고 systemd는 관리자에게 프로세스 기능에 대한 자세한 제어를 제공합니다.

리눅스는 커널 공격 표면을 줄이고 보안을 개선하기 위한 다양한 메커니즘을 제공하며, 이를 통칭하여 리눅스 보안 모듈 (LSM)이라고 합니다. 여기에는 NSA에서 의한 원래 코드를 개발하여 대중에 공개한 Security-Enhanced Linux (SELinux) 모듈과 AppArmor, 등이 포함됩니다. SELinux는 현재 GitHub에서 활발하게 개발 및 유지 관리되고 있습니다. SELinux와 AppArmor는 필수 접근 제어 (MAC)를 포함한 접근 제어 보안 정책에 대한 지원을 제공하지만 복잡성과 범위가 크게 다릅니다.

또 다른 보안 기능은 매개변수를 필터링하고 사용자-영역 응용 프로그램에서 사용 가능한 시스템 호출의 모음을 줄이는 방식으로 작동하는 Seccomp BPF (Berkeley Packet Filters를 갖는 SECure COMPuting)입니다.

비평가들은 커널 개발자들이 보안 결함을 은폐했거나, 적어도 이를 발표하지 않았다고 비난했습니다; 2008년에, Torvalds는 이에 대해 다음과 같이 응답했습니다:

저는 개인적으로 보안 버그는 그저 "통상적인 버그"라고 생각합니다. 저는 그것들을 은폐하지는 않지만, 이를 추적하고 특별한 것으로 발표하는 것이 좋은 생각이라고 생각할 이유도 전혀 없습니다...제가 보안 ​​서커스에 신경 쓰지 않는 한 가지 이유는 잘못된 행동을 미화하고—따라서 장려한다—고 생각하기 때문입니다. 그것은 보안 담당자를 "영웅"으로 만드는데, 마치 사람들은 통상적인 버그를 고치는 것 외에는 중요하지 않은 것처럼 말입니다. 사실, 모든 지루한 통상적인 버그는 "훨씬" 더 중요한데, 단지 왜냐하면 그것들이 훨씬 더 많기 때문입니다. 저는 어떤 엄청난 보안 홀이 나쁜 잠금으로 인한 무작위적인 엄청난 충돌보다 더 "특별"하다고 미화되거나 신경 쓰여서는 안 된다고 생각합니다.

리눅스 배포판은 전형적으로 리눅스 커널에서 취약성을 수정하기 위해 보안 업데이트를 릴리스합니다. 많은 배포판은 특정 리눅스 커널 버전에 대한 보안 업데이트를 장기간 받는 장기 지원 릴리스를 제공합니다.

Licensing terms

처음에, Torvalds는 임의의 상업적 사용을 금지하는 라이선스로 리눅스를 출시했습니다. 이것은 버전 0.12에서 GNU General Public License 버전 2 (GPLv2)로 전환되면서 변경되었습니다. 이 라이선스는 수정되거나 수정되지 않은 리눅스 버전의 배포와 판매를 허용하지만 모든 사본이 같은 라이선스로 출시되어야 하고 완전한 해당 소스 코드를 함께 동반되도록 하거나, 요청 시 자유롭게 접근이 제공되어야 합니다. Torvalds는 GPLv2 아래에서 리눅스에 라이선스를 부여한 것을 "내가 한 최고의 일"이라고 설명했습니다.

리눅스 커널은 명시적으로 GNU General Public License 버전 2 단독 (GPL-2.0-only)에 따라 라이선스가 부여되며, 함께 명시적인 syscall 예외 (Linux-syscall-note)가 있으며, 라이선스 소지자에게 공통적으로 GPL 확장인 이후 버전을 선택할 수 있는 옵션을 제공하지 않습니다. 기여된 코드는 GPL-호환 라이선스에 따라 제공되어야 합니다.

라이선스를 GPL 버전 (버전 3 포함)을 사용하도록 얼마나 쉽게 변경할 수 있는지에 대한 상당한 논란이 있었고, 이러한 변경이 바람직한지에 대한 논란도 있었습니다. Torvalds 자신은 버전 2.4.0이 출시될 때 자신의 코드는 버전 2에서만 출시된다고 구체적으로 밝혔습니다. 어쨌든, GPL의 약관에는 버전이 지정되지 않으면, 임의의 버전이 사용될 수 있다고 명시되어 있고, Alan Cox는 다른 리눅스 기여자 중에서 GPL의 특정 버전을 지정한 사람이 거의 없다고 지적했습니다.

2006년 9월, 29명의 핵심 커널 프로그래머를 대상으로 한 설문 조사에서 28명이 당시의 GPLv3 초안보다 GPLv2를 선호한다는 결과가 나왔습니다. Torvalds는 "저는 많은 외부인이... 제가 공개적으로 GPLv3의 열렬한 팬이 아니기 때문에 개인적으로는 이상한 사람이라고 생각했다고 생각합니다"라고 언급했습니다. Torvalds, Greg Kroah-Hartman, 및 Andrew Morton을 포함한 이 유명 커널 개발자 그룹은 대중 매체에 GPLv3에 대한 반대 의견을 밝혔습니다. 그들은 DRM/tivoization, 특허, "추가 제한"에 대한 조항을 언급했고 GPLv3에 의한 "오픈 소스 세계"의 발칸화를 경고했습니다. 리눅스 커널에 GPLv3를 채택하지 않기로 결정한 Torvalds는 몇 년 후에도 자신의 비판을 반복했습니다.

Loadable kernel modules

일부 로드-가능 커널 모듈 (LKM)이 저작권법에 따라 파생 작업으로 고려되어야 하는지, 그리고 이에 따라서 그것들이 GPL 조건에 해당하는지 여부에 대해 논쟁이 있습니다.

라이선스 규칙에 따라, 커널 인터페이스의 공개 부분집합만을 사용하는 LKM은 파생되지 않은 작업이며, 따라서 리눅스는 시스템 관리자에게 트리 외부 바이너리 객체를 커널 주소 공간에 로드하는 메커니즘을 제공합니다.

dma_buf 커널 기능을 합법적으로 사용하는 일부 트리 외부 로드 가능 모듈이 있습니다. GPL 호환 코드는 그것을 확실하게 사용할 수 있습니다. 어쨌든, 다른 가능한 사용 사례는 빠른 GPU와 Intel 통합 GPU를 페어링하는 Nvidia Optimus로, 여기서 Nvidia GPU는 그것이 활성화할 때 Intel 프레임버퍼에 씁니다. 그러나, Nvidia는 이 인프라를 사용할 수 없는데, 왜냐하면 그것은 역시 GPL인 LKM에 의해서만 사용될 수 있는 규칙을 우회해야 하기 때문입니다. Alan Cox는 LKML에서 Nvidia 엔지니어 중 한 명이 API에서 이 기술적 시행을 제거해 달라는 요청을 거부하며 답변했습니다. Torvalds는 LKML에서 "[저는] 바이너리 전용 커널 모듈이 "기본적으로" 파생되었다고 주장합니다"라고 분명히 언급했습니다.

다른 한편, Torvalds는 "[하나의] 회색 영역은 원래 또 다른 운영 시스템에 대해 작성된 드라이버와 같은 것입니다 (즉, 분명하게 원래 리눅스에서 파생된 작업이 아닙니다). 그것은 회색 영역이고, _그것_은 나 개인적으로 일부 모듈은 리눅스에 대해 설계되지 않았고 특별한 리눅스 동작에 의존하지 않는다는 이유만으로 파생 작업이 아닌 것으로 고려될 수 있다고 생각합니다". 독점 그래픽 드라이버가, 특히, 많이 논의됩니다.

독점 모듈이 리눅스에 로드될 때마다, 커널은 자체를 "오염됨(tainted)"으로 표시하고, 따라서 오염된 커널에서 버그 보고서는 종종 개발자에 의해 무시될 것입니다.

Firmware binary blobs

공식 커널, 그것은 kernel.org 저장소에서 Linus git 브랜치는 GNU GPLv2 라이선스의 조건 아래에서 릴리스된 바이너리 블롭을 포함하고 있습니다. 리눅스는 역시 파일 시스템을 검색하여 바이너리 블롭, 독점 펌웨어, 드라이버, 또는 기타 실행 가능 모듈을 찾은 다음 이를 커널 공간에 로드하고 연결할 수 있습니다.

그것이 필요할 때 (예를 들어, 부팅 장치 접근 또는 속도 향상을 위해), 펌웨어는 커널에 내장될 수 있으며, 이것은 펌웨어를 vmlinux에 빌드하는 것을 의미합니다; 어쨌든 이것은 기술적 또는 법적 문제로 인해 항상 실행 가능한 옵션은 아닙니다 (예를 들어, 비-GPL 호환하는 펌웨어를 갖는 이 작업을 수행할 수 없지만, 이것은 그럼에도 불구하고 꽤 흔합니다).

Trademark

리눅스는 미국, 유럽 연합, 및 기타 일부 국가에서 Linus Torvalds의 등록 상표입니다. 상표에 대한 법적 분쟁은 리눅스의 개발에 관여한 적이 없는 변호사, William Della Croce가 리눅스라는 단어 사용에 대한 라이선스 수수료를 요청하기 시작한 1996년에 시작되었습니다. Della Croce가 처음 사용했다고 주장한 것보다 훨씬 오래전부터 이 단어가 공통적으로 사용되었다는 것이 증명된 후, 상표는 Torvalds에게 수여되었습니다.

Removal of Russian maintainers

2024년 10월, 커널 개발자 Greg Kroah-Hartman은 러시아와의 연결을 암시하는 이메일 주소를 가진 일부 커널 개발자를 유지 관리자 역할에서 제거했습니다. Linus Torvalds는 러시아의 공격을 지지하지 않았고 패치를 되돌리지 않을 것이라고 답하면서 패치 반대자들이 러시아 트롤이라고 암시했습니다. 커널 개발자, James Bottomley는 상황 처리에 대해 사과를 발표했고 이 조치가 러시아에 대한 미국의 제재의 결과라고 명확히 했습니다.

Further reading

 

 

 

 

관련글

티스토리툴바