Linux/커널

Linux의 커널.

Linux 커널은 단일형 커널 구조를 가지며, 모듈화되어 있어, 컴파일 후에 모듈을 로드시킬 수 있다. 디바이스 드라이버가 이런 형태로 사용된다. 리눅스 커널 모듈은 .ko[1]의 확장자를 가지고 있다.

Linux는 커널에 대한 개별적인 설계를 통해 커널에 포함해야 할 기능을 최소화할 수 있다. 예를 들면 장치에 포함되지 않은 디바이스 드라이버는 포함하지 않을 수 있다. 그래서 똥컴이나 임베디드 시스템 등 성능이 낮거나 낡은 하드웨어라도 Linux를 사용할 수 있다.

통상적으로 커널 이미지는 /boot/vm[2]linu[3]z[4][5]-[커널 버전]-[기타][6]에 있다. [7]

과거의 Linux 커널과 배포판에서는 LILO(LInux LOader)를 사용했지만, 2000년대 이후의 Linux 배포판들은 GRUB을 사용한다.[8]

LILO는 하드디스크 상의 물리적인 위치를 기점으로 부팅을 하지만 GRUB는 파일명과 커널이 위치하고 있는 파티션을 기점으로 부팅하므로 커널을 업데이트하더라도 파일명만 바뀌지 않으면 그대로 부팅이 가능하다.

부트로더가 Linux 커널 이미지를 부트로더에서 설정된 파라미터와 로드하면, 부트로더가 압축 루틴으로 점프하여 커널을 압축해제하고, start_kernel() 함수를 실행시킨다. 이 함수는 스택과 BSS를 초기화하고, 나머지 부팅을 위한 하드웨어의 초기화 작업을 시행하고, 그 외의 나머지 하드웨어[9]를 초기화시킨다.

커널 초기화가 끝나면, initramfs를 임시로 / 디렉토리에 적재한다. 이 이미지는 최종적인 루트 파일시스템을 적재하기 위해 사용하는데 필요한 기본적인 유틸리티가 포함되어있다.
다음으로 initramfs 이미지 파일에서 /init 스크립트를 찾아 실행시킴으로써 루트 파일시스템을 적재시킨다. 이 스크립트는 다음과 같은 과정을 주로 거친다.

과거에는 initrd라는 압축된 파일시스템 이미지를 사용하였는데, 이는 실제 파일시스템을 압축시킨 것이어서, 실행하려면 램디스크를 로드하고 적재해야했다. 이 과정이 리소스를 많이 사용하여, 리눅스 커널 2.6.13부터 cpio 아카이브 형식을 사용해 메모리에 바로 적재될 수 있는 initramfs를 사용하기 시작했다.

이후 사용자 영역에 데몬 프로세스로 init를 생성하는데, 이 프로세스는 시스템 서비스를 실행하고 네트워크, 파일 시스템 등을 초기화한다. 이후 Linux 시스템의 전체적인 관리를 하는데 다음과 같은 역할을 한다.

한마디로 사용자 영역에서 사용자가 원하는 작업을 Linux 커널과 직접적으로 접촉하지 않으면서 할 수 있도록 하는 프로그램이라고 보면 된다.

init를 대체하기 위해서 등장한 것이 systemd인데, 데몬을 병렬로 실행하고 작은 데몬들은 단일 프로세스 내에 합쳐서 기능 추가와 부팅 속도 개선을 이뤘다. 그러나 기존의 init와는 설계 철학이 완전히 달랐기 때문에 등장 당시부터 큰 논란거리가 되었고, 대형 Linux 배포판은 2010년대 초반부터 중반 사이에 init에서 전환했으나 반감을 가진 Devuan 같은 일부 배포판은 systemd를 사용하지 않고 OpenRC같은 init을 사용하기도 한다. 특히 Gentoo Linux는 OpenRC를 사용할지 systemd를 사용할지 선택할 수 있다.

가상 파일 시스템은 여러 보조 저장 장치(USB 드라이브, SSD 등)를 하나처럼 작동하도록 보이게 하는 Linux 커널의 한 부분이다. Linux를 포함한 Unix 계열 운영체제에서는 모든 파일 시스템[15]을 Microsoft Windows에서처럼 C 드라이브, D 드라이브 등으로 나누지 않고, 하나의 계층 구조 아래에[16] 탑재하는데, 이를 가능하게 하는 것이 가상 파일 시스템이다.

모든 파일 시스템은 슈퍼블록이라는 구조체를 가지는데, 이 구조체는 파일 시스템에 관한 정보[17]를 저장한다. 가상 파일 시스템 레이어가 저장장치를 시스템에 탑재시킬 때, 이 구조체를 읽어들이고, 마운트 테이블에 이 구조체를 저장한다. 그리고 나서 파일 시스템의 정보를 저장할 공간을 메모리에 마련한 후, 해당 드라이브를 가상 파일 시스템에 통합시킨다.

리눅스 커널에는 파일 시스템을 위한 드라이버들이 있는데[18], 각 드라이버들은 가상 파일 시스템이 각 파일 시스템에서 필요로 하는 정보들을 채우도록 돕는 역할을 한다. 예를 들어 NTFS 파일시스템으로 포맷된 USB 드라이브에서 파일을 읽어온다고 하자. 파일을 불러오고 내용을 읽는 시스템 콜은 각각 하나 밖에 없는데[19], 각 파일 시스템마다 드라이브에 정보를 저장하는 방식이 다르기 때문에 그 시스템 콜에 NTFS 파일 시스템을 읽는 방법에 대한 코드를 직접적으로 탑재할 수는 없다. 따라서 NTFS을 비롯한 여러 파일 시스템들은 각자의 드라이버 소스코드 안에 자기들의파일 시스템에서 파일을 조작하는 함수를 미리 정의해놓아, 가상 파일 시스템은 현재 파일을 읽어야 하는 드라이브가 어떤 파일 시스템인지만 파악하고, 드라이버에 정의되어 있는 파일 불러오기와 읽기 함수를 실행하면 되도록 한다.

리눅스 커널은 모든 객체를 파일로 각주한다. 즉 텍스트 파일, 이미지 파일 같은 일반 파일, 디렉터리 뿐만 아니라 프로세스(/proc), 장치(/dev) 등도 논리적으로 파일로 각주된다. 리눅스는 파일 유형을 통해 해당 파일이 어떤 파일인지 구분하고 있다.

파일 시스템 내에서는 i-노드라고 표현된다. 모든 파일은 하나의 i-노드를 가지고 있으며 i-노드들은 파일 시스템의 i-리스트에 넣어서 관리된다. i-노드에는 파일의 소유자, 권한, 데이터 블록 수, 유형, 크기, 링크 수 등이 포함되어 있으며 해당 파일의 내용이 있는 데이터 블록에 대한 포인터 주소를 담고 있다.

파일의 권한의 경우 소유자(Owner), 그룹(Group), 기타(Other)로 나누어지고 각각 읽기(r), 쓰기(w), 실행(x) 권한이 존재하며, 이를 rwx로 표현한다. 소유자, 그룹, 기타의 권한을 모두 종합하면 다음과 같이 표현할 수 있다.

빨간색은 소유자의 권한, 파란색은 그룹의 권한, 초록색은 기타 사용자의 권한을 의미한다. 여기서 -로 표현하면 해당 권한이 없음을 의미할 수 있다. 예를 들면 다음과 같은 표현이 있다.

위 표현식에서는 소유자는 읽기, 쓰기, 실행 권한을 가지고 있지만 그룹 및 기타는 읽기 권한만 가지고 있다는 뜻이 된다.

리눅스 커널은 장치도 파일로 간주하는데, 이러한 파일들을 장치 파일이라 하고, 이 파일들은 컴퓨터에 연결된 장치를 파일 형태로 나타낸 인터페이스라고 볼 수 있다.

장치 파일은 블록 파일과 캐릭터 파일로 나뉜다. 블록 파일은 데이터를 고정된 크기의 바이트의 데이터를 포함한 블록으로 다루는 파일로, 임의적 접근이 가능하다. 주로 SSD, 하드 디스크 등과 같은 저장 장치가 블록파일 형식으로 나타난다. 캐릭터 파일은 데이터를 바이트 단위로 스트림 형식으로 송수신하는 파일로, 순차적 접근을 통해 상호작용한다. 키보드, 마우스, 프린터 등이 대표적인 캐릭터 장치이다.

이러한 장치들을 파일 형식으로 나타내면, 일반 파일을 다루듯이 읽고 쓰기를 통해 장치와 상호작용 할 수 있다. 더욱 세세한 조작을 위해서는 ioctl을 사용한다.

커널 모듈은 실시간으로 커널에 로드시키고 언로드할 수 있는 코드이다. Linux 커널 소스코드에서는 대부분이 드라이버용인데[20], 특정 하드웨어를 위한 드라이버가 없어 새로 만들었을 때 커널 모듈로 코드를 컴파일하여 커널에 로드시킬 수 있다. 만약 커널 모듈로 로드시킬 수 없다면, 기존 커널 소스와 통합시켜 커널 전체를 다시 컴파일해야했을 것이다.

커널 모듈은 insmod 명령어로 커널에 로드시킬 수 있고, rmmod 명령어로 로드해제할 수 있다. 현재 로드된 커널 모듈을 확인하는 것은 lsmod명령어로 확인할 수 있다.

리눅스에는 시스템 사용을 용이하게 하기 위한 특수 파일 시스템들이 존재한다. 이 파일 시스템들은 실제 저장장치의 데이터가 아닌 운영체제의 상태나, 연결된 장치들을 파일들로 표시할 때 사용된다.

현재 운영체제에 작동 중인 프로세스/프로그램의 상태, 시스템의 장치의 상태와 정보 등을 표시할 때 사용된다. 주로 리눅스 시스템의 /proc 디렉터리에 탑재되어 있다. 파일 시스템 내부에는 각 PID[21]의 번호를 이름으로 가진 디렉터리들이 있다.

이 외에도 시스템 정보를 담은 다양한 파일들이 있다.

커널 내부 데이터 구조에 대한 사용자 공간의 접근을 위한 의사 파일 시스템. 리눅스 커널에 대한 설정을 보거나 바꿀 수 있다. 리눅스에서는 주로 /sys 디렉터리에 마운트되어 있다.

시스템에 연결된 장치에 대한 디바이스 파일이 담긴 파일 시스템. 원래는 devfs였으나, 2005년 2.6.18 커널에서 삭제되고 udev 시스템과 더욱 잘 작동하는 devtmpfs로 바뀌었다.#

파일 시스템 내부에는 연결된 장치들과 의사 장치에 대한 파일들이 있다.

커널 설정을 생성한다. 크게 두 가지의 방법이 있다.

이제 설정한 커널을 빌드할 시간이다. make 명령으로 커널을, make modules 명령으로 커널 모듈을 빌드한다. 시간을 빨리 돌리고 싶다면 -j n 옵션으로 멀티태스킹을 활성화시킨다. n의 추천은 CPU의 가용 스레드 수 = 소켓 × 코어 × 논리적 스레드; 이다. 만약 SMT를 지원하는 6코어 CPU를 사용 중이라면 12개의 스레드를 동원할 수 있고 -j 12 옵션을 사용할 수 있다. 기본 옵션은 단일 스레드 동작이기 때문에 매우 느리다.

여기서부터 모든 명령어는 root로 실행하거나 sudo를 붙여서 실행해야 한다. 시스템을 변경하는 것이기 때문이다.

윈도우의 WSL 내 Linux 환경 자체는 대소문자를 구별하도록 되어 있지만 호스트 운영체제는 그렇지 않다. 따라서 WSL 내에 호스트 운영체제의 파티션을 마운트한 경로에서 작업을 하는 경우, 파일명이 충돌하는 문제가 발생할 수 있어 커널 컴파일 또한 정상적으로 진행되지 않을 수 있다.

컴파일 시간의 경우 선택한 옵션, 컴퓨터 성능, 병렬 작업 여부 등 수많은 변수가 있지만 [27] 평균적으로 고성능 컴퓨터에서는 30분에서 1시간 사이의 시간이 필요하다며 사양이 낮아질수록 시간은 더 오래 걸린다. 극단적으로 최적화를 하거나, 커널 커스터마이징이 필요하거나, Gentoo Linux, Linux From Scratch 등의 모든 것을 컴파일하는 배포판을 사용하지 않는 이상은 우분투 등의 바이너리 인스톨을 이용하는 배포판을 사용하는 것이 좋다. 2000년대의 Linux 관련 서적에서는 커널 컴파일이 후반부의 한 장 정도로 포함되어 있었으나, 이제는 Linux 커널 자체도 규모가 커졌고 커널 개발을 하지 않는다면 단순 사용을 위해서 커널을 직접 컴파일할 필요도 없어졌다.

Linux 커널의 가장 많은 부분을 차지하고 있는 부분은 드라이버 부분이 가장 많은 부분(1200만 줄)을 차지하고 있고 커널 자체의 코드 (12 만줄)크기는 상대적으로 작다. 그렇다 보니 임베디드 환경같이 커널 크기를 줄여야 하고 고정된 하드웨어에서만 작동해도 되는 환경에서는 드라이버를 쓸 부분만 남기고 전부 날려버려도 된다. 이 경우 컴파일 시간과 커널 이미지도 극적으로 줄어든다.

언어는 C언어를 중심으로 어셈블리어를 일부 사용하고 있다. C++의 사용은 리누스 토르발스가 의도적으로 막고 있다. 버전 6.1부터 러스트도 개발에 사용되지만 드라이버 개발부분에서 일부만 사용되고 핵심코어 부분은 여전히 C언어로만 개발된다. # 리눅스 드라이버에 러스트를 사용하는 것은 2025년까지도[28]논쟁이 되고 있는 실정이다.

현대에 와서는 코드의 양이 너무 많아져서, 한 사람이 Linux 커널에 대해 완전히 아는 건 불가능한 수준이 되었다. 2018년 기준 Linux 커뮤니티에 많이 기여하는 미국 대기업 기준으로 한 회사의 Linux 커널 개발자가 250~300여명 수준이다. 이런 수준의 개발자가 되기 위해서는 Linux 커널에 대한 책만 70여권 이상 읽어야 한다는 사람도 있다. 삼성전자 개발자들이 국내에서 가장 많이 기여하고 있는데 전체 연간 기여의 3%에 불과하다. 이런 회사 출신 개발자는 Linux 커널에 기여하는 게 곧 본인들 업무다. 2017년까지 약 1400여개의 회사에서 Linux 커널 개발에 참여했다. 연간 기여량의 약 40%를 20여개 대기업 [29]에서 담당하고 있다. 돈을 받지 않고 개인적으로 기여하는 사람의 비중은 약 10% 정도인데 이들은 점점 줄어들고 있다. 왜냐하면 너무나도 방대한 커널 코드에 지쳐 그만두거나, 기업에서 이들을 채용해 가기 때문이다.

Linux 커널의 개발은 크게 메인테이너(Maintainer)와 기여자(Contributor)로 나뉜다. 기여자가 패치를 보내면 메인테이너는 그 패치의 리뷰를 하고 서브시스템을 관리하는 등 중심적인 역할을 맡는다. 국내 Linux 커널 메인테이너는 2015년 기준 약 30여명으로 알려져 있다.

2022년 리누스 토발즈는 Linux 커널 개발자들이 고등학생처럼 벼락치기로 일정을 간신히 맞추거나 이마저도 지키지 못해 코드 제출이 늦는다고 깠다. #

리누스 토발즈는 동년 일본에서 개최한 리눅스 커널 소스에 Rust 도입 관련 인터뷰에선 요즘 너무 방대한 양의 소스를 관리한다면서 사실상 기여는 못하고 코드 리뷰나 컨펌만하는 신세라고 자신을 더 이상 프로그래머라고 부를 수 없을것 같다고 스스로 깠다.#

2025년 3월엔 늦잠자느라 까먹고 리눅스 커널 6.14 릴리즈를 못했다고 자신은 아침형 인간이 아니라고 스스로를 깠다.#

1991년 4월 리누스 토르발스는 80386 보호모드에서 돌아가는 첫 Linux 커널의 개발을 시작했다. 8월 말 완료된 0.01 버전의 코드 라인은 10,239줄이었다. 2015년 6월 공개된 버전 4.1은 약 1950만줄 이상이고 14,000여명의 프로그래머가 기여했다. [30]

1996년 버전 2.0이 나온 이후에는 약 2년마다 마이너 버전(0.x)이 올라가고[31], 약 2개월마다 패치 버전(0.0.x)이 오르는 식이었으나, 2.6 버전은 이례적으로 7년 넘게 유지되었다. 결국 2011년 7월 리누스 토르발스가 버전 명명 규칙을 바꾸면서 버전이 3.0으로 올라갔고, 마이너 버전이 19~20 정도 나온 후에는 메이저 버전이 올라가게 되었다. 즉 버전 3.0부터는 메이저 버전이 바뀌었다 해서 꼭 내용물이 크게 바뀌었다는 것을 의미하지는 않는다.

2012년 12월경 버전 3.8부터는 처음 지원했던 80386 지원을 중단했다.

2018년 버전 4.17부터는 Blackfin, CRIS, FRV, M32R, Metag, MN10300, Score, Tile 등 관리가 되지 않았던 CPU 명령어 집합 지원을 중단하고 관련 드라이버 50만줄을 소스코드에서 삭제했다.

2021년 리누스 토르발스는 아이테니엄 시리즈가 2021년 2월 단종되자 바로 아이테니엄 시리즈 지원중단을 선언했다. 12월에는 3DNow! 처럼 인텔에 밀려 잘 사용되지 않는 AMD 자체 명령어 셋 지원도 중단했다. #

2022년 버전 6.1부터 HEDT CPU 지원 강화 및 손상된 코어 감지가 지원된다 또한 장치 드라이버 개발부분에서 Rust가 도입된다. 그리고 빅리틀 프로세서를 위한 새로운 프로세스 스케줄링 Nest가 도입된다. 또한 인텔 80486, 펜티엄 지원도 중단했다. 실제로 6.1.2커널을 적용한 Tinycore Linux 14.0 버전은 펜티엄 MMX급 이상에서만 동작한다고 한다.