리눅스 커널
1. 개요
1. 개요
리눅스 커널은 리눅스 운영 체제의 핵심 구성 요소이다. 리누스 토르발스가 1991년 9월 17일 최초로 공개한 이 커널은 컴퓨터의 하드웨어와 소프트웨어 사이에서 중재자 역할을 수행한다. 메모리 관리, 프로세스 관리, 장치 드라이버 제어, 시스템 호출 처리, 보안 등 운영 체제의 가장 기본적이고 필수적인 기능들을 담당한다.
이 커널은 단일형 커널 구조를 채택하고 있다. 이는 커널의 핵심 기능들이 하나의 큰 주소 공간에서 실행됨을 의미하며, 성능상의 이점을 제공한다. 동시에 높은 유연성을 위해 모듈화 설계를 도입하여, 필요에 따라 커널 모듈 형태로 기능을 실시간으로 로드하거나 언로드할 수 있다. 이 방식을 통해 디바이스 드라이버나 파일 시스템 지원과 같은 기능을 주 커널 이미지에서 분리할 수 있어, 시스템을 최소화하거나 특정 하드웨어에 맞춰 구성하는 것이 가능해진다.
리눅스 커널은 주로 C 언어로 작성되었으며, 일부 아키텍처 의존적인 저수준 코드에는 어셈블리어가 사용된다. 공식 소스 코드는 kernel.org 웹사이트를 통해 배포 및 관리된다. 이 커널은 서버, 데스크톱, 임베디드 시스템, 스마트폰(안드로이드)에 이르기까지 다양한 컴퓨팅 환경의 기반이 되고 있으며, 전 세계 수많은 개발자들이 참여하는 대표적인 오픈 소스 프로젝트로 성장했다.
2. 역사
2. 역사
리눅스 커널의 개발은 1991년 4월, 핀란드 헬싱키 대학의 학생이었던 리누스 토르발스가 개인 프로젝트로 시작했다. 그는 인텔 80386 프로세서의 보호 모드에서 동작하는 운영 체제 커널을 만들고자 했으며, 같은 해 9월 17일에 최초 버전인 0.01을 공개했다. 이 초기 코드는 약 1만 줄에 불과했다.
지속적인 개선을 거쳐 1994년 3월 14일에 정식 버전 1.0이 출시되었다. 이후 커널은 급격히 성장하여 2015년 공개된 버전 4.1 기준으로 약 1950만 줄의 코드와 1만 4천 명 이상의 기여자를 자랑하게 되었다. 버전 관리 체계도 진화했는데, 2011년 7월 리누스 토르발스는 기존의 규칙을 변경하여 메이저 버전 번호를 더 자주 올리기 시작했다. 이로 인해 버전 3.0 이후부터는 메이저 버전 변경이 반드시 큰 기술적 변화를 의미하지는 않게 되었다.
시간이 지남에 따라 오래된 하드웨어 및 명령어 집합에 대한 지원이 단계적으로 중단되었다. 대표적으로 2012년 12월경 버전 3.8부터 초기 지원 대상이었던 인텔 80386 지원이 중단되었고, 2022년 버전 6.1부터는 인텔 80486 및 초기 펜티엄 시리즈에 대한 지원도 종료되었다. 이처럼 리눅스 커널은 방대한 오픈 소스 프로젝트로 성장하면서도 현대 컴퓨팅 환경에 맞춰 지속적으로 진화하고 있다.
3. 특징
3. 특징
3.1. 단일형 커널 구조
3.1. 단일형 커널 구조
리눅스 커널은 단일형 커널 구조를 채택한다. 이는 마이크로커널 구조와 대비되는 개념으로, 운영체제의 핵심 기능인 프로세스 관리, 메모리 관리, 파일 시스템, 장치 드라이버, 네트워크 스택 등이 모두 커널 공간에서 실행되는 하나의 큰 프로그램으로 구성됨을 의미한다. 이러한 설계는 구성 요소 간의 통신이 함수 호출을 통해 이루어지므로 성능상의 이점을 제공한다.
단일형 구조의 단점은 커널이 거대해지고 복잡성이 증가한다는 점이다. 이를 보완하기 위해 리눅스 커널은 모듈화를 적극적으로 도입했다. 핵심 커널은 최소한의 기능만 포함하고, 대부분의 장치 드라이버나 특정 파일 시스템 지원과 같은 기능은 필요 시 동적으로 로드 및 언로드할 수 있는 커널 모듈 형태로 제공된다. 이로 인해 사용자는 자신의 하드웨어에 꼭 필요한 드라이버만 로드하여 시스템 자원을 효율적으로 사용할 수 있으며, 커널을 재컴파일하지 않고도 새로운 기능을 추가할 수 있다.
따라서 리눅스 커널은 단일형 커널의 성능과 모듈화의 유연성을 결합한 구조라고 볼 수 있다. 이는 서버, 데스크톱, 임베디드 시스템 등 다양한 환경에서 리눅스가 널리 사용될 수 있는 기반이 되었다.
3.2. 모듈화
3.2. 모듈화
리눅스 커널은 단일형 커널 구조를 채택하고 있지만, 높은 유연성을 제공하기 위해 모듈화 설계를 도입했다. 이 모듈화의 핵심은 커널 모듈 시스템이다. 커널 모듈은 실행 중인 커널에 동적으로 로드하거나 언로드할 수 있는 코드 조각으로, 주로 장치 드라이버를 구현하는 데 사용된다.
이 설계의 가장 큰 장점은 커널의 핵심 기능을 최소화할 수 있다는 점이다. 예를 들어, 특정 하드웨어에 대한 드라이버가 필요하지 않다면 해당 모듈을 커널에 포함시키지 않아도 된다. 이는 리소스가 제한된 임베디드 시스템이나 구형 하드웨어에서도 리눅스를 효율적으로 실행할 수 있게 해준다. 사용자는 insmod 명령어로 모듈을 로드하고, rmmod 명령어로 제거하며, lsmod 명령어로 현재 로드된 모듈 목록을 확인할 수 있다.
커널 모듈은 .ko 확장자를 가지며, 필요에 따라 컴파일하여 생성한다. 만약 모듈 형태로 제공되지 않는 새로운 기능이나 드라이버를 추가해야 한다면, 사용자는 커널 소스 코드 전체를 수정하고 재컴파일해야 하는 번거로움을 겪게 된다. 따라서 모듈화는 시스템의 유연성과 확장성을 크게 향상시키는 핵심 메커니즘이다.
4. 기술적 구성
4. 기술적 구성
4.1. 부트 과정
4.1. 부트 과정
리눅스 커널의 부트 과정은 컴퓨터 전원이 켜진 후 운영체제가 메모리에 적재되어 실행을 시작하기까지의 일련의 단계를 말한다. 이 과정은 BIOS나 UEFI와 같은 시스템 펌웨어가 제어권을 부트로더에 넘기고, 부트로더가 최종적으로 커널을 메모리에 로드하며 시작된다. 대부분의 현대 리눅스 배포판은 GRUB을 주된 부트로더로 사용한다.
부트로더가 커널 이미지와 초기 RAM 디스크(initramfs)를 메모리에 로드한 후, 제어권을 커널에 넘기면 본격적인 커널 초기화가 진행된다. start_kernel()이라는 함수가 실행되어 CPU 및 메모리 관리, 인터럽트 시스템 등 핵심 하드웨어를 초기화한다. 이후 커널은 initramfs 이미지를 임시 루트 파일 시스템으로 메모리에 마운트한다. 이 이미지에는 실제 루트 파일 시스템을 마운트하는 데 필요한 최소한의 유틸리티와 커널 모듈이 포함되어 있다.
initramfs 내의 /init 스크립트가 실행되면, procfs, sysfs, devtmpfs 같은 가상 파일 시스템을 마운트하고, 하드드라이브나 네트워크 등에서 최종적인 루트 파일 시스템을 찾아 / 디렉토리에 적재한다. 이 모든 준비가 완료되면, 커널은 사용자 공간의 첫 번째 프로세스인 init 프로세스 (또는 현대 시스템에서는 systemd 같은 대체 프로그램)를 실행한다. 이 프로세스는 시스템 서비스를 시작하고 런레벨을 관리하며, 최종적으로 사용자가 로그인할 수 있는 완전한 운영체제 환경을 제공한다.
4.2. 가상 파일 시스템
4.2. 가상 파일 시스템
가상 파일 시스템은 리눅스 커널이 다양한 종류의 실제 파일 시스템을 하나의 통일된 계층 구조 아래에서 관리할 수 있게 해주는 추상화 계층이다. 유닉스 계열 운영체제의 철학에 따라, 하드 디스크, USB 드라이브, SSD와 같은 서로 다른 저장 장치에 위치한 파일 시스템들을 C:, D: 드라이브와 같이 구분하지 않고, 단일 루트 디렉토리(/) 아래에 통합하여 마운트하는 방식을 가능하게 한다.
이를 구현하기 위해 가상 파일 시스템은 모든 파일 시스템이 공통으로 제공해야 하는 슈퍼블록, inode, 디렉토리 엔트리 등의 객체와 이를 조작하는 시스템 콜 인터페이스를 정의한다. 실제 파일 시스템 드라이버(예: ext4, NTFS, FAT32)는 이 인터페이스를 구현하여 커널에 등록한다. 사용자나 응용 프로그램이 read(), write()와 같은 시스템 콜을 호출하면, 가상 파일 시스템은 요청이 대상으로 하는 파일이 속한 실제 파일 시스템의 드라이버를 찾아 해당 드라이버가 구현한 구체적인 함수를 호출한다. 이로 인해 사용자는 하부의 복잡한 저장 방식과 무관하게 일관된 방식으로 파일에 접근할 수 있다.
가상 파일 시스템의 또 다른 중요한 역할은 활성 파일 시스템과 마운트 지점에 대한 정보를 유지하는 것이다. 커널은 마운트 테이블을 관리하여 어떤 장치가 어떤 디렉토리에 마운트되었는지, 해당 파일 시스템의 슈퍼블록은 어디에 있는지 추적한다. 이 메커니즘 덕분에 심볼릭 링크와 하드 링크가 다른 파일 시스템에 걸쳐 존재할 수 있으며, mount 및 umount 명령어를 통한 동적인 파일 시스템 변경이 가능해진다.
4.3. 커널 모듈
4.3. 커널 모듈
커널 모듈은 리눅스 커널이 부팅된 후에도 동적으로 로드하거나 제거할 수 있는 코드 조각이다. 주로 디바이스 드라이버를 구현하는 데 사용되며, 파일 시스템이나 네트워크 프로토콜과 같은 커널 기능을 확장하는 데에도 활용된다. 이 모듈화된 구조는 커널의 핵심 기능을 최소화하면서도 다양한 하드웨어와 기능을 유연하게 지원할 수 있게 해준다. 특히 임베디드 시스템이나 서버 환경에서 필요에 따라 메모리 공간을 절약하고 성능을 최적화하는 데 중요한 역할을 한다.
커널 모듈은 일반적으로 .ko 확장자를 가지며, 사용자 공간에서 insmod 명령어로 커널에 로드하고 rmmod 명령어로 제거할 수 있다. 현재 시스템에 로드된 모듈 목록은 lsmod 명령어로 확인 가능하다. 모듈이 로드되면 커널의 일부처럼 동작하며, 커널 공간의 메모리를 사용하고 시스템 콜 인터페이스를 통해 사용자 프로세스와 상호작용한다. 이 방식은 새로운 하드웨어에 대한 지원을 추가하거나 커널 기능을 업데이트할 때 전체 커널을 재컴파일하고 시스템을 재부팅할 필요 없이 실시간으로 적용할 수 있다는 장점이 있다.
커널 모듈의 개발과 관리는 모듈화 원칙에 따라 이루어진다. 각 모듈은 명확한 인터페이스를 통해 커널과 통신하며, 필요한 심볼을 내보내거나 외부 심볼을 사용한다. 모듈 간의 의존성은 modprobe 명령어가 자동으로 처리한다. 또한, 모듈 서명과 같은 보안 메커니즘을 통해 신뢰할 수 없는 코드의 로드를 방지하여 시스템의 안정성과 보안을 강화한다. 이는 마이크로커널 구조와 달리 단일형 커널인 리눅스가 모듈성을 유지하며 확장되는 데 기여하는 핵심 요소이다.
4.4. 특수 파일 시스템
4.4. 특수 파일 시스템
리눅스 커널은 시스템의 상태와 하드웨어 정보를 파일 형태로 제공하기 위해 여러 특수 파일 시스템을 구현한다. 이들은 실제 저장 장치에 데이터를 저장하는 일반 파일 시스템과 달리, 커널 내부의 다양한 정보와 객체를 사용자 공간에서 접근할 수 있는 인터페이스로 제공하는 것이 주된 목적이다. 대표적으로 procfs, sysfs, devtmpfs가 있으며, 이들은 각각 /proc, /sys, /dev 디렉터리에 마운트되어 운영된다.
procfs는 프로세스 정보와 시스템 상태를 제공하는 데 중점을 둔다. /proc 디렉터리 아래에는 각 실행 중인 프로세스의 PID를 이름으로 하는 하위 디렉터리가 존재하며, cmdline, status, fd 등의 파일을 통해 해당 프로세스의 명령행 인자, 상태, 열린 파일 디스크립터 등을 조회할 수 있다. 또한 /proc/cpuinfo, /proc/meminfo, /proc/version과 같은 파일들은 시스템의 CPU, 메모리, 커널 버전 정보를 제공한다.
sysfs는 커널 객체들의 계층적 표현을 제공하며, 주로 /sys에 마운트된다. 이 파일 시스템은 시스템에 연결된 장치, 버스, 드라이버 등의 커널 내부 데이터 구조를 사용자 공간에 노출시킨다. 예를 들어 /sys/class에는 네트워크, 그래픽, 입력 장치 등의 클래스별 디렉터리가, /sys/bus에는 PCI, USB 등의 버스별로 탐지된 장치 정보가 담겨 있다. 이를 통해 사용자는 하드웨어 구성과 상태를 파악하고, 일부 커널 매개변수를 동적으로 변경할 수도 있다.
devtmpfs는 시스템 부팅 초기에 장치 파일을 동적으로 생성하고 관리하는 역할을 한다. 이전의 devfs를 대체하여 도입되었으며, 주로 /dev 디렉터리에 마운트된다. 이 파일 시스템은 물리적 저장 장치(/dev/sdX, /dev/nvmeXnY), 가상 터미널(/dev/ttyX), 특수 장치(/dev/null, /dev/random) 등의 파일을 제공하여, 사용자 애플리케이션이 하드웨어 장치와 상호작용할 수 있는 표준화된 인터페이스를 만든다.
5. 개발
5. 개발
5.1. 개발 언어
5.1. 개발 언어
리눅스 커널은 주로 C 언어로 작성된다. 이는 커널의 초기 개발자이자 현재까지도 최고 관리자인 리누스 토르발스가 선택한 언어로, 하드웨어에 대한 저수준 제어와 높은 성능이 필요한 운영체제 핵심 부분을 구현하는 데 적합하기 때문이다. 커널의 대부분의 코드, 예를 들어 프로세스 관리, 메모리 관리, 파일 시스템, 네트워크 스택 등의 핵심 서브시스템은 C 언어로 구성되어 있다.
성능이 극도로 중요하거나 특정 하드웨어 레지스터를 직접 조작해야 하는 일부 부분에서는 어셈블리어가 사용된다. 이는 주로 아키텍처별 부트 코드나 인터럽트 처리 루틴과 같이 플랫폼 의존적인 최적화가 필요한 영역에 국한된다.
다른 고수준 언어의 도입에 대해서는 신중한 접근을 유지해 왔다. 예를 들어, C++는 리누스 토르발스가 의도적으로 커널 개발에서 배제해 왔다. 그러나 최근에는 Rust 언어가 일부 영역, 특히 새로운 장치 드라이버 개발을 위한 보조 언어로 도입되었다. 버전 6.1부터 실험적으로 지원되기 시작했으나, 이는 커널의 핵심 코드를 대체하기보다는 모듈 개발 등 특정 부분에서의 사용을 목표로 한다.
5.2. 개발 모델
5.2. 개발 모델
리눅스 커널의 개발 모델은 전 세계 수천 명의 개발자가 참여하는 대규모 오픈소스 협업의 대표적인 사례이다. 이 모델은 리누스 토르발스가 시작한 개인 프로젝트에서 출발하여, 점차 수많은 기업과 개인 개발자들이 기여하는 생태계로 성장했다. 개발 과정은 메일링 리스트와 Git을 기반으로 한 분산형 패치 관리 시스템을 통해 이루어진다. 주요 결정은 토르발스를 비롯한 상위 메인테이너들이 논의를 거쳐 내리며, 이들은 각자 담당하는 서브시스템의 코드 리뷰와 통합을 책임진다.
개발 참여 구조는 크게 메인테이너와 기여자로 나뉜다. 기여자는 새로운 기능 추가나 버그 수정을 위한 패치를 작성하여 해당 서브시스템의 메인테이너에게 제출한다. 메인테이너는 이 패치를 검토하고 테스트한 후, 적합하다고 판단되면 자신이 관리하는 Git 트리에 병합한다. 이후 이러한 변경 사항들은 주기적으로 리눅스 커널 메인라인 트리로 통합된다. 이 과정에서 리누스 토르발스는 최종 병합 결정을 내리는 역할을 수행한다.
이 모델의 특징은 엄격한 기술적 검증과 공개적 논의에 기반한다는 점이다. 모든 패치는 공개 메일링 리스트를 통해 검토받으며, 때로는 수많은 피드백과 수정을 거쳐야 한다. 또한, 기업의 참여가 매우 활발하여, 삼성전자, 레드햇, 인텔, 구글과 같은 대기업들이 상당 부분의 개발 인력을 투입하고 있다. 이로 인해 커널 개발은 개인의 취미 프로젝트를 넘어 산업계의 핵심 인프라를 구축하는 협업 프로젝트의 성격을 띠게 되었다.
5.3. 버전 관리
5.3. 버전 관리
리눅스 커널의 버전 관리 체계는 시간이 지남에 따라 진화해왔다. 초기에는 메이저 버전과 마이너 버전이 명확히 구분되는 전통적인 방식을 따랐다. 1991년 9월 17일 최초 공개된 버전 0.01부터 시작하여, 1994년 3월 14일 정식 출시된 버전 1.0에 이르기까지 점진적으로 발전했다. 이후 1996년 버전 2.0이 출시된 후 약 2년마다 마이너 버전이 올라가는 패턴을 보였으나, 버전 2.6은 약 7년 동안 장기간 유지되는 이례적인 사례가 되었다.
이러한 장기간의 유지 관리를 거친 후, 2011년 7월 리누스 토르발스는 버전 명명 규칙을 변경하여 버전 3.0을 출시했다. 새로운 규칙 하에서는 메이저 버전 번호가 더 자주 올라가게 되었으며, 이는 반드시 기술적으로 획기적인 변화를 의미하지는 않는다. 예를 들어, 마이너 버전이 19~20 정도 누적된 후에는 메이저 버전이 증가하는 방식이 되었다. 이 체계는 현재까지도 이어지고 있으며, 리눅스 커널은 지속적으로 새로운 메이저 버전을 출시하고 있다.
버전 관리와 함께 중요한 부분은 오래된 하드웨어 및 아키텍처에 대한 지원 중단이다. 커널은 새로운 기술을 수용하기 위해 구형 지원을 정리해왔다. 예를 들어, 2012년 12월경 버전 3.8부터는 초기부터 지원했던 인텔 80386 프로세서 지원이 중단되었다. 이후에도 관리되지 않는 여러 CPU 명령어 집합에 대한 지원이 단계적으로 중단되었다. 2022년 버전 6.1부터는 인텔 80486 및 펜티엄 프로세서 지원도 공식적으로 종료되었다.
6. 커널 컴파일
6. 커널 컴파일
6.1. 준비 및 설정
6.1. 준비 및 설정
커널 컴파일을 시작하기 전에 필요한 의존성 패키지를 설치하고 작업 환경을 준비해야 한다. 우선 빌드 도구인 make, 컴파일러인 gcc와 g++, 어셈블러 및 링커를 포함하는 binutils가 최소 요구사항이다. 또한 ncurses 라이브러리는 텍스트 기반 설정 인터페이스를 사용하는 데 필요하다. 아치 리눅스와 같은 일부 배포판에서는 xmlto, kmod, inetutils, bc, libelf, git, cpio, perl, tar, xz 등의 추가 패키지도 권장된다.
커널 소스 작업을 위한 전용 디렉터리를 생성한 후, 리눅스 커널 아카이브에서 원하는 버전의 커널 소스 아카이브(예: linux-(버전).tar.xz)를 다운로드한다. 보안을 위해 다운로드한 파일의 디지털 서명과 체크섬을 반드시 검증해야 한다. 압축을 해제한 후, make mrproper 명령어를 실행하여 소스 트리 내의 모든 이전 구성 파일과 빌드 산출물을 정리하는 것이 좋다. 이는 깨끗한 상태에서 빌드를 시작하는 데 도움이 된다.
커널 구성을 생성하는 방법은 크게 두 가지이다. 기존 시스템에서 컴파일하는 경우, 현재 실행 중인 커널의 설정을 베이스로 삼을 수 있다. /proc/config.gz 파일의 내용을 .config 파일로 복사하거나, make localmodconfig 명령을 사용하여 현재 로드된 커널 모듈만을 기반으로 한 최소 구성을 자동 생성할 수 있다. 완전히 새로운 구성을 직접 작성하려면 make menuconfig(텍스트 기반), make xconfig(KDE 기반), make gconfig(GTK 기반) 등의 명령어로 다양한 설정 인터페이스를 사용할 수 있다. 이 단계에서 시스템에 필요한 장치 드라이버, 파일 시스템 지원, 네트워크 프로토콜 등 핵심 기능을 선택하게 된다.
6.2. 빌드 및 설치
6.2. 빌드 및 설치
커널과 모듈의 빌드가 완료되면, 시스템에 설치하는 과정이 필요하다. 이 과정은 시스템의 핵심 부분을 변경하는 작업이므로, 모든 명령어는 root 사용자 권한으로 실행하거나 sudo를 사용해야 한다.
먼저 make modules_install 명령을 실행하여 컴파일된 커널 모듈을 시스템의 적절한 위치(일반적으로 /lib/modules/ 디렉토리 아래)에 설치한다. 다음으로, 생성된 커널 이미지 파일을 /boot 디렉토리로 복사한다. x86 또는 x86_64 아키텍처의 경우, 이 파일은 arch/x86/boot/bzImage 경로에 있으며, vmlinuz-(커널 버전)과 같은 형식의 이름으로 복사하는 것이 일반적이다. 만약 /boot가 별도의 파티션으로 마운트되어 있다면, 복사 전에 해당 파티션을 마운트해야 한다.
시스템이 정상적으로 부팅되기 위해서는 초기 램디스크 이미지(initrd 또는 initramfs)가 필요하다. 이 이미지는 부팅 초기 단계에서 실제 루트 파일시스템을 마운트하는 데 필요한 핵심 모듈과 유틸리티를 포함한다. 배포판에 맞는 도구(예: mkinitcpio, dracut, update-initramfs)를 사용하여 이 이미지를 생성하고 /boot 디렉토리에 복사해야 한다. 또한, 커널 심볼 정보를 담고 있는 System.map 파일도 /boot 디렉토리에 복사하며, 문제 분석을 위해 사용된 설정 파일(.config)을 /boot에 보관하는 것도 좋은 방법이다.
마지막으로, GRUB이나 LILO와 같은 시스템의 부트로더 설정을 업데이트하여 새로 설치된 커널을 부팅 옵션에 추가해야 한다. 설정을 완료한 후 시스템을 재부팅하면 새로운 커널로 부팅된다.
7. 지원 아키텍처 및 중단
7. 지원 아키텍처 및 중단
리눅스 커널은 다양한 컴퓨터 아키텍처를 지원하는 것이 주요 특징 중 하나이다. 초기에는 인텔 IA-32 아키텍처(특히 80386)를 중심으로 개발되었으나, 시간이 지나면서 ARM, MIPS, 파워PC, RISC-V 등 수많은 CPU 아키텍처에 대한 포팅이 이루어졌다. 이는 리눅스가 서버, 데스크톱 컴퓨터, 임베디드 시스템, 슈퍼컴퓨터 등 광범위한 플랫폼에서 사용될 수 있는 기반이 되었다.
지원이 중단된 아키텍처도 존재한다. 하드웨어의 구식화와 유지 관리 부담을 이유로, 커널 개발 커뮤니티는 더 이상 활발히 사용되지 않는 일부 아키텍처에 대한 지원을 공식적으로 중단하고 관련 코드를 삭제해 왔다. 예를 들어, 2012년 12월경 버전 3.8부터는 초기 지원의 상징이었던 인텔 80386 아키텍처 지원이 중단되었다. 이후 2018년 버전 4.17에서는 Blackfin, CRIS, FR-V 등 관리가 되지 않던 여러 아키텍처 지원이 중단되고 관련 코드가 대거 제거되었다.
최근에도 지원 중단은 계속되고 있다. 2021년에는 인텔 아이테니엄 시리즈가 단종되자 해당 아키텍처 지원 중단이 선언되었고, AMD의 3DNow! 명령어 셋 지원도 중단되었다. 2022년 버전 6.1부터는 인텔 80486 및 초기 펜티엄 프로세서에 대한 지원이 공식적으로 제거되어, 현대 리눅스 커널은 더 이상 이러한 매우 오래된 x86 프로세서에서 동작하지 않게 되었다. 이러한 결정은 코드베이스를 간소화하고 현대 하드웨어에 대한 개발과 최적화에 집중하기 위한 것이다.
