리눅스 2.6의 멋진 세상

Joseph Pranevich - jpranevich AT kniggit.net

Translated by Nate Park (박종구) - youlsa AT i-on.net

첫번째 2.4 시스템이 부팅한 것이 엊그제 같은데 시간은 어느덧 흘러 리눅스 2.6이 세상에 나오게 되었다. 이 문서는 i386 플랫폼을 중심으로 리눅스 커널 2.6의 전반적인 면에 대한 설명을 위한 문서이다. 여기에 설명하는 새로운 기능들 중 몇몇은 공식적으로 또는 배포판 관리자들에 의해 커널 2.4로 백포팅(back-porting)된것도 있을 것이다. 그 외에도 커널 2.4의 유지보수 과정에서 추가된 기능들에 대한 설명도 함께 하도록 하겠다.

현재 이 문서는 10여개의 언어에 대한 번역문서가 존재하며 문서의 제일 아랫쪽을 참조해주기 바란다.

지금까지의 이야기들...

리눅스 커널은 리누스 토르발즈가 그의 386 컴퓨터에서 실행가능한 미닉스(minix)와 비슷한 운영체제를 만들기 시작한데서 시작되었다. (처음에 리누스는 운영체제의 이름을 Freax라고 짓고 싶었다고 한다) 싱글 CPU의 i386머신에서만 실행 가능한 리눅스 커널 1.0의 공식 릴리즈는 1994년 3월이었다. 그로부터 1년 후인 1995년 3월에 최초로 i386이 아닌 플랫폼에서 실행가능한 (그러나 여전히 싱글 CPU에서만 동작하는)리눅스 1.2가 릴리즈 되었다. 1996년 6월에 리눅스 2.0이 릴리즈 되었다. 2.0에는 동작 가능한 여러 플랫폼이 추가 되었지만 무엇보다도 다중 CPU를 갖는 머신(SMP)에서 동작하는 최초의 버전이었다. 2.0의 릴리즈 이후 주요 버전의 릴리즈 속도는 다소 늦춰졌다. (리눅스 2.2가 1999년 1월, 2.4가 2001년 1월에 각각 릴리즈 되었다) 하지만 각각의 마이너 버전업은 자주 일어나 지원되는 하드웨어의 범위와 확장성이 개선되어 갔다. (리눅스 2.4는 최초로 ISA 플러그앤 플래이와 USB, PC 카드 등의 기능이 추가되어 최초로 사용자들의 데스크탑에서 쓸만한 버전이었다는 점도 주목할만 하다) 리눅스 2.6은 2003년 12월 17일에 릴리즈 되었다. 2.6은 다양한 추가 기능도 기능이지만 매우 대용량 시스템에서부터 아주 작은 시스템(PDA등)까지 고루 지원한다는 점에 있어서 또 한번의 큰 개선버전이기도 하다.

핵심 하드웨어 지원

리눅스의 가장 강력한 점 중 하나는 그 유연성과 지원 하드웨어의 광범위함에 있다. 이 문서는 i386 기반의 PC에서의 사용에 중점을 맞추고 있기는 하지만 리눅스 2.6의 뛰어난 하드웨어 지원은 짚고 넘어갈만 하다.

축소 - 임베디드 시스템을 위한 리눅스

리눅스 커널 2.6의 중요한 두가지 변화 중 하나는 유씨리눅스(uClinux) 프로젝트를 메인 커널에 병합했다는 것이다. 유씨리눅스 프로젝트는 마이크로 콘트롤러를 위한 리눅스를 제작하는 프로젝트이다. 유씨리눅스는 이미 임베디드 시장에서는 주요 OS중 하나로 인정받고 있기 때문에 메인 커널에 이를 병합 하는 것은 앞으로의 임베디드 시장에서 리눅스의 발전에도 큰 힘이 된다고 볼 수 있다. 일반적인 리눅스 커널과는 달리 임베디드 플랫폼에 사용되는 리눅스 커널은 하드웨어적 제약 때문에 몇가지 제한이 있게 된다. 가장 중요한 점 하나는 MMU(메모리 관리 유닛 - 프로텍티드 모드의 핵심적 기능을 한다)가 없다는 것이다. 물론 그래도 멀티태스킹 운영체제이기는 하다. (메모리 관리 기능이 없을 경우 한 프로세스가 다른 프로세스의 데이타 영역에서 자료를 읽고 쓰거나 심지어는 프로세스 자체를 망가뜨릴 수도 있다) 하지만 이런 경우 멀티 유저 시스템을 구성하기가 곤란해지지만 PDA와 같은 저가형 소형 디바이스들의 경우에는 훌륭한 선택일 수도 있다. 이런 아키텍쳐 변화가 중요한 것은 2.6 이전까지의 리눅스 커널은 사실상 리누스의 초기 작업들이 수행된 인텔 80386 플랫폼의 영향이 상당히 많이 남아 있었다는 점 때문이다.

리눅스 커널 2.6에서 히타치 H8/300시리즈, NEC v850, 모토롤라의 m68k 임베디드 프로세서 등이 추가적으로 지원되기 시작했다. 보통 리눅스 사용자들이 처음으로 사용하는 PDA가 팜 파일럿 계열인 경우가 많기 때문에 모토롤라의 프로세서들은 어느 정도 친숙할 것이다. 모토롤라나 Lineo, Arcturus등의 Dragonball, Cold Fire같은 제품들이 지원된다. 슬프게도 MMU가 없는 예전의 m68k 계열의 CPU들은 지원되지 않는다. (올드맥에 사용되는 CPU이다) 누군가가 취미 프로젝트로 오래된 머신들에 리눅스를 포팅하는 프로젝트를 시작할 수도 있을 것이다.

유씨 리눅스 통합의 일부는 아니지만 리눅스 커널 2.6에는 Axis Communications의 ETRAX CRIS(Code Reduced Instruction Set)가 지원된다. (사실 이 기능은 2.4 릴리즈 이후 유지보수의 과정에서 추가되었다) 이것들은 주로 네트웍 하드웨어에 사용되는 MMU가 포함된 임베디드 프로세서이다. MMU가 포함되지 않은 프로세서에 대한 지원도 외부 프로젝트로 수행되고 있는 것으로 안다.

하드웨어 지원에 덧붙여 메인 커널에 임베디드에 관한 부분을 통합하여 얻게 된 이점들이 여러가지가 있지만 겉으로 보기에는 특별해 보이지는 않지만, 몇몇 변화사항들, 예컨데 스왑 없이도 시스템을 구성할 수 있는 능력 등등이 커널을 더욱 견고하게 만든 점등이 있을 수 있다.

대규모로 -- NUMA와 대규모 기계들

리눅스 커널 2.6의 근본적인 두가지 변화 중 나머지 하나는 아이러니하게도 앞의 것과 정반대 방향으로의 확장이다. 리눅스가 더욱 더 대규모 서버에서 사용 가능하도록 하는 방향이다. (큰 시스템들 중 어떤 시스템은 i386 기반이겠지만 어떤 것은 아니다) 이 방향에서의 리눅스의 가장 큰 변화는 NUMA 서버의 지원이다. NUMA(Non-Uniform Memory Access)의 지원은 멀티 프로세싱에 있어서 SMP에서 한걸음 더 나아간 것으로 많은 CPU를 가진 시스템에서 좀 더 효율적으로 동작할 수 있게 해주는 첫걸음이라고 할 수 있다. 다중 CPU 서버에서는 단일 메모리 버스에 여러개의 CPU들이 동시에 억세스를 하게 되는데 여기에서 병목현상이 발생하게 된다. NUMA 서버에서는 이런 문제를 각각의 CPU에게 다른 메모리보다 가까운 메모리를 지정해주도록 함으로써 해결한다. 기술적으로 정확한 표현은 아니지만, 이렇게 상상하면 쉽다. 시스템이 여러장의 카드로 이루어 졌다고 상상해보자. 각각의 카드들은 각각 자신만의 CPU와 메모리, 입출력 장치들을 가지고 있다. 시스템에 이런 카드들이 많이 있다고 생각하면 각각의 CPU는 (물론 다른 카드의 메모리와 통신을 할수도 있겠지만) 자신과 같은 카드에 있는 메모리가 가장 가깝고 속도도 빠를 것이다. NUMA 아키텍쳐는 이런 식으로 타이트하게 구성된 클러스터라고 생각할 수 있다.

이런 NUMA 머신들을 효율적으로 지원하기 위해 리눅스 커널에서는 몇가지 개선사항을 도입하였다. 우선, 리눅스 커널 내부에서 각각의 프로세서와 메모리들, 입출력 장치들의 관계를 알아낼 수 있도록 위상(topology) API들이 추가되었다. 이를 기반으로 커널의 프로세스 스케쥴러는 최대한 효율적으로 가까운 리소스가 어떤 것인지를 이해하고 활용할 수 있게 된다. 추가적으로 많은 NUMA 머신들은 각 노드가 차지하고 있는 메모리 사이에 구멍이 뚫리도록(어드레스 공간이 연속적이 않다는 뜻) 구현되어 있는데 리눅스 커널에서는 이런 비연속적인 메모리도 제대로 다룰 수 있다. 여기에 언급한 것들 말고도 리눅스 커널에는 대용량의 서버들을 제대로 지원할 수 있는 여러가지 개선사항들이 개선되었고 앞으로도 더욱 많은 개선이 있을 것이다.

서브 아키텍쳐(subarchitecture) 지원

앞서의 두가지 변화사항만큼 큰 변화는 아니지만 리눅스 커널의 새 버전에는 더욱 많은 머신에서 리눅스를 실행시킬 수 있도록 해주는 서브 아키텍쳐(subarchitecture)라는 개념이 구현되었다. 이전 버전까지의 리눅스 커널에서는 CPU의 종류와 아키텍쳐의 종류가 일치한다고 가정해왔다. 예를 들어 CPU가 i386이라면 무조건 PC/AT 아키텍쳐 기반의 PC라고 가정을 했던 것이다. 리눅스 2.4에서 이러한 가정이 깨졌는데 SGI의 Visual Workstation때문이었다. CPU만 인텔의 칩이였고 아키텍쳐가 PC와는 완연히 다른 기계이다. (물론 다른 아키텍쳐에서는 그 전에도 이 가정이 깨지긴 했다. m68k 아키텍쳐에서 Amiga, 매킨토시 등이 동시에 지원되는 등의 예가 있었다.) 하지만 리눅스 커널 2.6에서의 큰 변화는 모든 아키텍쳐에 대해 동일한 방법으로 서브 아키텍쳐를 지원할 수 있도록 표준화 되었다는 것이다.

이런 표준화 덕분에 i386에서도 두개의 새로운 플랫폼이 추가 지원된다. 첫번째는 NCR의 Voyager 아키텍쳐이다. 이것은 32개까지의 486-686 CPU를 지원하는 SMP 시스템이다 (현재의 표준인 인텔 MP 스펙이 나오기 전에 나온 시스템이다). 실제 판매된 갯수는 그리 많지 않고 판매된 모든 기계가 지원되는 것은 아니다. (최초에 판매된 머신들은 지원되지 않는다) 새로 추가된 두번째 플랫폼은 NEC가 개발하여 비교적 최근까지 일본 시장에서 독점적 위치를 차지하고 있던 PC-9800이다. PC-9800은 8086에서 시작하여 펜티엄급과 SMP까지 지원되던 성숙한 플랫폼이었다. (물론 리눅스 커널은 80386이상의 머신에서만 동작한다) 미국에는 전혀 소개되지 않았지만 마이크로 소프트의 윈도우 95까지 이 머신에서 동작하도록 포팅되어 판매된 바 있다. 하지만 그 이후에는 표준 PC가 그 자리를 대치해가고 결국 단종되었다.

이런 "약간만 다른" 하드웨어 타입들을 지원할 수 있는 구조 덕분에 앞으로 스토리지 기기라던가 유명 CPU를 사용하는 머신들에 대한 지원이 손쉬워졌다. 하지만 이것이 만능은 아니다. 이런 서브 아키텍쳐는 IRQ 라우팅과 같이 하드웨어의 최하위 레벨의 콤포넌트가 다른 점을 커버하기 위해서 나온 것이다. PC와 거의 동일하지만 아주 약간만 다른 엑스박스에서 리눅스를 돌리는 것과는 다르다는 점을 명심해야 한다.

하이퍼쓰레딩

리눅스 커널 2.6에서의 또다른 큰 진보 중 하나는 하이퍼 쓰레딩의 지원이다. 하이퍼 쓰레딩은 현재 최신 펜티엄 4에서만 지원되고 있으나 다른 곳에서도 지원할 수 있을것이다. 하드웨어 적으로 하나의 CPU를 두개나 그 이상의 CPU로 보이도록 해주는 기술이다. 이것은 어떤 경우에는 큰 퍼포먼스 향상을 불러오지만 스케쥴링의 복잡성이 증가하는 원인이 되기도 한다. 커널의 개선사항중 하나는 이제는 커널이 전 CPU(실제이건 가상이건)에 걸쳐 부하를 분산하고 최적화를 할 수 있다는 점이다. 이전 버전의 리눅스 커널에서는 전체적인 부하를 계산할 수 없어서 한개의 CPU가 혹사당하는 일이 잦았었다. 대단한 점은 리눅스 커널이 시장에서 이 기능을 제일 깔끔하고 지능적으로 지원하고 있다는 점이다. (윈도우 2000 서버는 가짜 CPU들을 볼 수 있으나 가상 CPU로 이용하려면 추가 CPU 라이센스가 필요했다. 마이크로 소프트가 이 기능을 제대로 지원하게 되는 것은 윈도우 XP 부터이다)

리눅스 내부

확장성의 개선

앞서 나열한 NUMA나 하이퍼쓰레딩과 같은 일반적인 기능들 이외에도 리눅스2.6은 인텔 CPU 기반 서버를 십분 활용하게 해주는 기능들을 가지고 있다. 가장 중요한 개선사항은 PAE(Physical Address Extension)이라고 부르는 인텔 하드웨어의 기능이다. 이것은 최신의 32비트 x86 시스템들이 64GB까지의 RAM을 페이지 모드로 읽을 수 있도록 해주는 기능이다. 멀티 CPU 시스템에서의 APIC 지원 개선을 통한 IRQ 밸런싱 기능도 상당히 개선되었다.

새로운 하드웨어 기능 추가 이외에도 내부적 한계치들이 가능한한 최고 수준까지 높여졌다. 예를 들어 유니크한 사용자와 그룹의 수가 65,000에서 40억으로 늘어(16비트에서 32비트로 늘어난 것이다) 리눅스를 파일서버나 인증서버로 활용하는데 지장이 없도록 개선되었다. 프로세스 ID(PID)의 갯수도 32,000개에서 10억개로 증가하여 uptime이 매우 길고 바쁜 서버에서 새로운 프로세스를 생성하는 퍼포먼스가 향상되었다. 열수 있는 최대한의 파일의 갯수는 늘지 않았지만 이전과 같이 미리 원하는 한계치를 지정하지 않아도 자동으로 늘도록 수정되었다. 마지막으로 리눅스 2.6에서 블럭 디바이스들이 64비트를 지원할 수 있도록 수정되었다. i386과 같은 32비트 플랫폼에서도 마찬가지이다. 그래서 일반적인 하드웨어에서 파일 시스템을 16TB 까지 사용할 수 있게 되었다.

리눅스 커널 2.6의 확장성에 대한 개선사항 중 또다른 중요한 점은 커널 자체가 디바이스의 여러 타입을 지원하는 것 뿐만 아니라 한가지 타입의 여러가지 디바이스의 종류를 지원한다는 사실이다. 지금까지의 리눅스들은(사실은 거의 모든 유닉스가 그러하지만) 시스템의 사용자와 프로그램들이 숫자가 메겨진 디바이스 노드와 통신을 하도록 되어 있다. (/dev 디렉토리의 항목들) 이 디바이스 노드들은 255개의 주 디바이스로 제한되고 각각 255개의 부 디바이스로 제한된다. 예를 들어 /dev/sda2라는 디바이스는 첫번째 SCSI 드라이브의 두번째 파티션이라는 뜻인데 주 디바이스 번호가 8이고(SCSI가 다 그렇다) 부 디바이스 번호가 2이다. 다른 타입의 디바이스들은 각각의 주 디바이스 번호와 부 디바이스 번호를 할당 받는다. 하지만 255개 이상의 디바이스가 필요한 서버에서는 난관에 봉착하게 된다. (대형 스토리지 어레이, 프린트 팜 등) 리눅스 2.6에서는 이러한 제한들이 4096 주 디바이스와 각각에 100만개의 부 디바이스를 가질 수 있도록 확장되었다. 현재 나와 있는 최고 사양의 머신들도 아무런 문제없이 지원할 수 있도록 되었다.

상호작용성과 응답성

확장성과 함께 새 버전의 개발과정에서 중요하게 여겨진 것은 시스템의 응답성이다. 이것은 일반적인 데스크탑 사용자뿐만 아니라 고도의 정확성을 요구하는 응용 프로그램에게도 유용하다. 물론 이런 개선에도 불구하고 리눅스 2.6은 여전히 리얼타임 OS는 아니다. 리얼타임 OS가 되기 위해서는 액션에 대한 응답이 정해진 시간 안에 분명히 보장되어야 하고 예측가능해야 한다. 그럼에도 불구하고 이러한 응답성의 개선은 모든 계층의 리눅스 사용자들에게 호평받을 것이다. (물론 리얼타임 OS의 기능을 제공하기 위한 프로젝트가 존재한다. 이 프로젝트는 다음번 메이저 릴리즈에 공식적으로 공표될 것이다)

리눅스 커널 2.6의 가장 중요한 개선 사항중 하나는 드디어 커널 자체가 선점형으로 동작한다는 것이다. 이전 버전의 리눅스에서 커널 자체가 작업을 하는 동안에는 다른 프로세스를 위한 인터럽트를 허용하지 않아왔다. (물론 다중 CPU인 시스템에서는 CPU당 그렇다) 리눅스 2.6에서는 커널 자체가 작업을 하는 도중에도 인터럽트되어 다른 어플리케이션이 자신의 작업을 해나갈 수 있다. 물론 여전히 커널이 처리하는 도중에 인터럽트 되지 않는 작업이 있기는 하다. 하지만 실제 상황에서 너무나 짧은 시간이라 대부분의 사용자들은 그 딜레이를 거의 눈치채지 못할 것이다. 결국, 시스템에 부하가 많이 걸리는 상황에서도 사용자의 입력에 대해 시스템이 매우 빠르게 동작하는 것을 느끼게 될 것이다.

리눅스의 입출력 서브시스템들에 대폭적인 수정이 가해져서 큰 부하 아래에서도 응답성이 좋아지도록 개선되었다. 이것은 I/O 스케쥴러를 재작성하여 구현되었다. I/O 스케쥴러는 특정 시간에 어떤 프로세스가 디바이스들을 점유할 것인지를 결정하는 역할을 하는 커널 내의 루틴이다. 새로 작성된 스케쥴러는 한 프로세스가 너무 오랫동안 대기하지 않도록 효율적인 배분이 가능하게 해준다.

어플리케이션 측면에서 리눅스용 프로그램들의 응답성이 개선되도록 돕기 위해 새로운 futex(Fast User-Space Mutex)가 지원된다. Futex는 여러 프로세스나 쓰레드들 사이에서의 레이스 컨디션(race condition)을 피할 수 있도록 이벤트들을 시리얼라이즈(serialize)되도록 한다. 기존의 Mutex와는 달리 Futex는 절반 정도는 커널에 기반하고 우선순위가 높은 어플리케이션이나 쓰레드가 리소스에 우선적으로 접근할 수 있도록 한다. 프로그램이 태스크들에 우선순위를 먹여 이를 기반으로 Mutex를 걸도록 함으로써 반응시간을 향상 시킬 수 있는 것이다.

위의 것들에 덧붙여 많은 경우에 응답성을 강화해주는 소소한 개선사항들이 포함되어 있다. 이중 하나는 이른바 "Big Kernel Lock"을 제거했다는 것과 파일시스템 미리 읽기의 최적화, 소규모 파일 처리 등등이 그것이다.

기타 개선 사항들

다른 오픈소스 프로젝트들도 그렇듯이 리눅스는 오픈 스탠다드를 지향한다. 커널 2.6의 주요 개선 사항중 하나는 쓰레드 구조의 변경을 통해 POSIX 쓰레드 라이브러리(NPTL)을 돌릴 수 있다는 것이다. 이것은 많은 쓰레드를 동시에 돌리는 펜티엄 프로나 그 이상의 프로세서에서 큰 퍼포먼스 개선효과를 보여주며, 아마도 엔터프라이즈 시장에서 가장 각광 받을 개선사항일 수 있을 것이다. (사실 레드햇은 이미 이 기능을 2.4로 백포트(backport)하여 레드햇 9와 어드밴스드 서버 3.0에 포함시켰다) 이 변화는 쓰레드 그룹, 각 쓰레드의 로컬 메모리, POSIX 스타일의 시그널 등과 같은 리눅스 쓰레드의 새로운 컨셉들을 포함한다. 한가지 단점은 몇몇 버전의 Sun Java와 같이 예전의 리눅스를 기준으로 작성된 어플리케이션들이 제대로 동작하지 못할수도 있다는 것이다. 하지만 장점이 워낙 크기 때문에 대부분의 문제 어플리케이션들도 결국에는 새 커널을 제대로 지원할 것이다.

모듈 서브시스템과 통합 디바이스 모델

요즘의 운영체제들은 수많은 종류의 내부/외부 버스와 디바이스들을 다루어야만 한다. 새 버전의 리눅스에서 이 점이 대폭 보강된 것도 그리 놀라울 일은 아니다. 모듈 로더뿐만이 아니라 하드웨어에 대한 이해방식 자체도 상당한 변화가 있다. 변화된 부분은 우스울 정도로 간단한 것부터 시작해서 (드라이버 모듈이 이전에는 ".o"확장자를 가졌는데 이제는 커널 오브젝트를 뜻하는 ".ko"로 바뀐 것) 크게는 통합 디바이스 모델(unified device model)의 도입까지이다. 모두 안정성의 개선과 이전 버전의 한계를 극복하기 위한 방향으로 작업이 진행되었다.

모듈 서브 시스템의 안정성을 강화하기 위해 많은 큰 변화사항들이 존재한다. 모듈을 내리는(unload) 경우 모듈이 사용중인 와중에 내리게 되는 경우를 줄었다. 이전에는 대부분 시스템 크래쉬를 유발하는 경우가 많았었다. 안정적으로 돌아가야 하는 서버들을 위해 모듈을 내리는 기능을 아예 꺼버릴 수도 있게 했다. 추가적으로 각 모듈이 자신이 어떤 하드웨어를 지원하는지 알도록 하고 이를 공표할 수 있는 공표하는 표준절차가 마련되었다. 이전 버전의 리눅스에서는 각 모듈이 자신이 지원하는 하드웨어가 무엇인지는 알고 있었지만 이 정보가 모듈 밖에서는 공유되지 못했었다. 이 개선사항 덕분에 레드햇의 kudzu와 같은 하드웨어 관리 프로그램들이 좀 더 지능적으로 개선될수 있게 되었다. 공식적으로는 지원되지 않으나 거의 비슷한 구조를 가진 하드웨어에 대해 드라이버에게 특정 하드웨어에 대해 강제로 동작하도록 하는 것이 가능해졌다.

새 커널 버전에서는 모듈 로딩 이외에도 디바이스 모델 자체가 상당한 변화를 겪었다. 정해진 디바이스를 감지하는 등의 단순한 역할만을 행하는 모듈 로더와는 달리 디바이스 모델은 시스템 내의 하드웨어 전반에 대한 책임을 지는 좀 더 깊은 개념이다. 리눅스 2.2 이전에는 모듈 레벨에서만 모든 것을 판단하는 통합 디바이스 모델의 가장 간단한 서포트만이 존재했었다. 지금까지는 이러한 구조로도 충분했으나 ACPI등 최신 하드웨어 기능들을 모두 이용하기 위해서는 각 디바이스가 사용하는 리소스만 아는 것으로 충분하지 않다. 디바이스가 사용하는 버스의 종류라던가 가지고 있는 부디바이스의 종류나 현재의 전원공급 상태, 충돌시 사용 리소스를 바꾸어야 하는지 여부 등의 여러가지 상태들을 파악하고 있어야만 한다. 심지어는 현재의 디바이스에 알맞은 모듈이 이미 로드되어 있는지 여부도 파악할 수 있어야만 한다. 리눅스 커널 2.4에서 PCI와 PC 카드, ISA, PnP 버스들을 동일한 인터페이스로 묶을 수 있는 통합 인터페이스가 도입되었다. 리눅스 2.6에서는 새로운 형식의 커널 오브젝트(kobject)를 통해 시스템의 디바이스 지원을 한 차원 높이 끌어올리고 있다. 레퍼런스 카운팅이나 전원 관리, 유저 스페이스(user-space)와의 연결 방법 제공 등 더 나은 통합된 인터페이스를 제공한다.

디바이스들에 대한 자세한 정보가 커널에 모두 제공되므로 랩탑이나 데스크탑 컴퓨터들에 대한 좀 더 심도 깊은 지원이 가능해졌다. 가장 좋아지는 부분은 PC카드나 USB, Firewire, 핫플러그 PCI등의 핫 플러그(hot plug)기기들에 대한 부분이 될 것이다. 되돌아 생각해보면 리눅스 2.2 이전까지는 이런 종류의 하드웨어 지원이 전무했었다. 근래에는 핫 플러그 방식으로 동작하는 기기가 예외적인 상황이 아니라 일반적인 경우가 되었으므로 새로운 디바이스 관리 시스템에서 기존의 디바이스와 핫 플러그 디바이스의 차이점을 제거하는 것이 꼭 필요했다. 커널의 서브 시스템에서 부팅시에 찾아낸 디바이스와 실행중에 찾아낸 디바이스의 차이점을 차별하지 않음으로써 핫 플러그 방식의 디바이스를 처리하는 방식이 간단해졌다. 이번 버전에서 새로 작성되고 개선된 부분은 전원 관리에 대한 부분이다. 최근에 새로운 표준으로 사용되는 ACPI(Advanced COnfiguration and Power Interface)는 지난 버전에 약간 엉성한 방식으로 지원됐었다. 이전의 표준이었던 APM(Advanced Power Management)와는 달리 ACPI를 사용할 때에는 OS가 모든 디바이스들에게 전원 공급 상태를 바꾸도록 통보해야 한다. 하드웨어 전체에 대한 정보를 모두 파악하고 있지 않다면 커널이 이런 통보 작업을 하는 것이 불가능할 것이다. 이 두가지 예로 든 것들 이외에도 통합의 효과로 이득을 보는 몇몇 분야들이 있다. 하드웨어의 연결시험(auditing)이나 감시 등이 그것이다.

마지막으로 (그리고 가장 중요한지도 모르지만) 시스템 파일시스템가 분화된 것이 중요한 변경사항이다. 시스템 파일 시스템은 "sysfs"라고 부르는데 프로세스는 'proc', 디바이스들은 'devfs', UNIX98 수도터미널(pseudo-terminal)들은 'devpts'이다. /sys에 마운트되는 이 파일 시스템은 커널이 디바이스를 어떻게 보는지 그대로 보여준다. (물론 예외도 있다) 검색된 디바이스의 속성의 갯수를 포함해서 디바이스의 이름과 IRQ, DMA, 전원 공급 상태 등의 사항들을 커널이 어떻게 파악하고 있는지 알 수 있다. 물론 이런 변화는 단기적으로는 혼란을 초래할 수도 있지만 결국에는 잘 이전될 것이다. 약간의 과도기가 있을 것이다.

시스템 하드웨어 지원

리눅스가 주류로 나아가면서 각각의 커널에서 지원하는 디바이스들이 비약적으로 늘고 있다. 비교적 새로운 기술(USB 2.4등)이나 기존의 오래된 기술들(MCA 2.2등)도 포함된다. 커널 2.6이 발표되면서 리눅스가 지원하지 않는 하드웨어는 비교적 적다. 하지만 아직도 지원되지 않는 PC 하드웨어들이 있다. 그렇기 때문에 유연성을 향상시키기 위해 새로운 기능을 추가하기 보다 i386 하드웨어의 지원이 개선되는 것이다.

내장 디바이스

프로세서의 타입과 거의 동일한 수준으로 비슷한 것이 시스템이 어떤 버스를 사용하고 있는지 여부이다. PC 업계에는 예전의 ISA를 비롯하여 현재의 외부 시리얼 장치나 와이러리스 버스에 이르는 필요 이상으로 많은 종류의 버스가 혼재되어 사용되고 있다. 리눅스는 언제나 최신의 버스나 디바이스가 발표되고 인기를 끌게 되면 즉시 이를 차용하여 지원하도록 하고 있지만 비교적 덜 인기가 있는 기술에 대해서는 조금은 느린 대응을 보이고 있다.

리눅스의 시스템 내부 디바이스에 대한 지원은 비교적 공명정대하다. 가장 좋은 예가 ISA 플러그앤 플레이에 대한 지원이다. 리눅스는 커널 2.4 이전까지는 어떠한 PnP에 대한 지원도 제공하지 않았었다. 하지만 이 지원은 PnP BIOS의 지원이 구현되면서 모두 지원되기 시작했다. 디바이스 이름에 대한 데이타베이스나 기타의 호환성에 대한 것들이 변화되면서 그렇게 되었다. 결과적으로는 이제 리눅스는 진정한 플러그앤 플레이 운영체제가 되어 버렸다. 다른 오래된 버스들, 예컨데 MCA나 EISA등이 모두 새로운 디바이스 모델에 포함되어 한꺼번에 구현된 것이다. 커널 2.6에서는 PCI(Peripheral Component Interconnect) 서브 시스템의 개선 사항에 포함하여 몇가지 이슈들이 개선되었다. 핫 플러그 PCI, 전원 관리, 다수 AGP의 지원, 등이다. 마지막으로 이런 버스들과 함께 리눅스 2.6에서는 "legacy" 버스라는 개념을 포함한다. 이것은 각각의 버스에 대해 거의 반드시 있을만한 디바이스에 대한 정보를 미리 가지고 있는 것이다. 예를 들자면 PC에서는 온보드 시리얼 포트, 패러렐 포트, PS/2 포트등이 어떤 버스에나 거의 반드시 포함되어 있는 디바이스들이다. 물론 이런 지원을 하기 위해서는 펌웨어를 억세스 하는 등의 좀 더 복잡한 작업이 수반되지만 일반적으로는 새로운 드라이버 패러다임에 걸맞는 방식으로 모든 디바이스들을 제어하도록 하는 수단이 된다.

외장 디바이스

최근의 개발 과정 동안 약간 오래된 내부 디바이스 버스들에 대한 새로운 기능추가가 좀 덜했던 것은 사실이지만 새로운 외장 하드웨어에 대한 지원은 그렇지 않다. 이쪽으로 가장 중요한 개발 사항 중 하나는 USB 2.0 디바이스에 대한 지원이다. 이들 디바이스들은 고속 USB 디바이스라고 불리는데 480Mbps의 속도가 나와 이전의 12Mbps로 동작하던 USB 디바이스들과 대조를 이룬다. 이것과 관련된 최신 표준인 USB OTG(USB On-the-go)는 현재 리눅스 2.6에서는 지원되지는 않는다. (이것은 PC를 끼지 않고 디지탈 카메라를 프린터에 연결하는 등의 일을 가능하게 해준다) (이에 대한 패치는 존재하지만 아직 메인 커널에는 통합되지 않았다) 이외에도 USB 디바이스들을 파악하는 루틴이 새로 작성되어 동일한 타입의 디바이스가 여러개일 때에도 잘 동작하도록 수정되었다. 이런 큰 변화들 말고도 리눅스 유저들을 위해 USB 디바이스들의 안정성, 호환성이 향상되도록 개발 과정에서 많은 배려가 있었다.

이런 것들과 정반대의 방향에서, 리눅스 2.6에서는 리눅스 시스템이 USB 호스트가 아닌 USB 디바이스로 동작하는 것이 가능하도록 하는 부분이 추가되었다. 예를들어 리눅스 기반의 PDA가 PC에 연결되어 제대로 동작할 수 있도록 하는 등의 일들을 위한 기반이 마련되었다. 임베디드 디바이스에서 리눅스가 제대로 사용되기 위해 꼭 필요한 기능이라고 할 수 있다.

무선 디바이스

최근 몇년간 무선 디바이스들의 사용이 인기를 끌기 시작했다. 어떨 때에는 케이블이라는 것이 과거의 유물이고 몇년 안에 사라질 것처럼 생각되기도 한다. (물론 전원 케이블은 예외이다) 무선 디바이스에는 가장 흔히 쓰이는 네트웍 디바이스 부터 PDA와 같은 기기까지 포함한다.

무선 네트웍 분야에서 디바이스들은 보통 장거리 (아마추어 무선을 통한 AX.25) 디바이스와 단거리 (802.11 등) 디바이스로 나뉜다. 이들 각각의 디바이스들에 대한 지원은 리눅스 커널의 초창기인 1.2 시절부터 시작되었으며 커널 2.6에서 새로 갱신되었다. 가장 큰 변화는 단거리 무선 인터넷 기기들이 모두 "wireless"라는 부 시스템과 API로 통합되었다는 사실이다. 이런 통합은 디바이스의 종류별로 다른 설정을 해주어야 하는 문제를 해결하여 모든 디바이스에 대해 동일한 동작을 하는 사용자 프로그램의 작성을 가능하게 해준다. 이런 통합 이외에도 디바이스의 동작 상태 변경에 대한 통지라던가(로밍과 같은) 무선 디바이스에서 일어나는 주기적인 딜레이에 대한 TCP 차원의 처리와 같은 개선사항들이 포함되었다. 커널 2.4 사용자들로부터 무선 디바이스의 지원에 대한 요구가 많기 때문에 이들 많은 개선사항들이 2.4로 백포트 되어있기도 하다.

일반적인 무선 디바이스 분야에서 IrDA와 같은 디바이스에 대해 전원 관리라던가 커널 드라이버 모델로의 통합과 같은 개선사항이 있다. 그리고, 블루투스 디바이스들에 대한 지원에 비약적 향상이 있었다. 블루투스는 IrDA와 비슷하기는 하나 시거리가 확보되지 않아도 사용 가능한 단거리 저전력형 무선 디바이스 통신 방식이다. 프로토콜로서의 블루투스는 PDA나 핸드폰, 프린터, 자동차용 디바이스들과 같은 어떤 분야에서도 사용될 수 있도록 설계된 프로토콜이다. 프로토콜 자체는 두가지 방식으로 이루어져 있는데 오디오 데이타와 같이 손실 가능성 데이타를 전송하는데 주로 쓰이는 SCO(Synchronous Connection Oriented)방식과 정밀한 데이타 전송이 필요한 부분에 쓰이는 L2CAP(Logical Link Control and Adaptation Protocol)이 그것들이다. L2CAP 프로토콜은 많은 서브 프로토콜(sub-protocol)들을 지원한다. (포인트 투 포인트 네트워킹을 위한 RFCOMM, 이더넷과 같은 네트워킹을 위한 BNEP등) 블루투스를 활용하기 위한 리눅스의 지원은 날이 갈수록 향상되어가고 있고 소비자들이 더 많은 블루투스 디바이스들을 사용하게 되면 될수록 그 지원도 향상될 것이다. 최초의 블루투스 지원은 커널 2.4에서 시작되었다는 점도 특기할 만 하다.

블록 디바이스 지원

스토리지 버스

IDE/ATA(integrated DRive Electronics/Advanced Technology Attachment)나 SCSI(Small Computer System Interface)와 같이 스토리지 전용으로 사용되는 버스들은 커널 2.6 개발 과정에서 메이저 업데이트가 있었다. IDE 서브 시스템에 대한 부분이 가장 중요 한데. 확장성에 대한 문제들을 여러가지 다른 제약점을 해결하기 위해 커널 2.6의 개발 과정에서 완전히 새로 작성되었다. 예를 들어 이제 CD/RW 드라이브들은 이전 버전에서와 같이 SCSI 에뮬레이션을 통해 동작하는게 아니고 직접 디바이스와 통신할 수 있도록 개선되었다. 그리고 150MB/sec의 속도를 갖는 시리얼 ATA(S-ATA)디바이스들에 대한 지원이 추가되었다. SCSI 측면에서는 넓은 지원 범위와 확장성을 위한 여러가지 개선사항이 추가되었다. SCSI-2 멀티패스(multi-path) 디바이스에 하나의 디바이스에 2LUN을 갖는 경우에 같이 예전 방식에 대한 대한 지원도 추가되었다. (SCSI-2는 1994년으로 거슬러 올라가는 SCSI 표준의 이전 표준이다) 그리고 이제 리눅스도 윈도우와 같이 미디어의 교환을 감지해낼 수 있도록 개선되어 완전히 표준을 따르지 않는 디바이스들과도 호환성을 유지할 수 있도록 했다. 이들 기술들이 시간이 흐름에 따라 안정화 되어가기 때문에 이들에 대한 리눅스의 지원도 안정화 되어가고 있다.

물론 그 자체로는 스토리지 버스가 아니지만 리눅스는 EDD(Enhanced Disk Device) BIOS를 직접 지원할 수 있게 되었다. EDD BIOS는 바이오스가 알고 있는 시스템에 연결된 모든 디바이스에 대한 정보를 가지고 있다. (IDE와 SCSI를 모두 포함하여) 게다가 설정사항과 기타 정보들만 가지고 오는 것이 아니라 몇가지 장점들을 더 제공한다. 예를 들어, 새 인터페이스는 리눅스가 부팅할 때 어느 디스크 디바이스를 이용했는지를 알아낼 수 있게 하는 등의 새로운 인터페이스를 제공한다. 리눅스 설치시 어느 부분에 리눅스 부트 로더를 설치할 것이지를 지능적으로 결정하게 해주는 등의 좀 더 지능적인 설치 프로그램을 작성할 수 있게해준다.

이런 변화 사항들 이외에도 모든 버스 디바이스 타입들이 리눅스의 새로운 디바이스 모델 서브 시스템으로 통합 되었다는 점이 중요하다. 어떤 경우에는 이런 통합이 좀 우스워 보일수도 있을 것이고, 또 다른 어떤 경우에는 좀 더 심각한 변화사항들이 있는 경우도 있을 것이다. (예를 들어 디바이스가 수정이 필요한지 등에 대한 감지를 하는 로직 자체도 변화될 필요가 있다)

파일 시스템

리눅스에서 블럭 디바이스 시스템을 사용하는 부분은 당연히 파일 시스템을 얹어서 쓰기 위해서이다. 리눅스 커널 2.4 이후로 많은 부분에서 광범위한 개선이 있었다. 그중 가장 중요한 점들은 확장 속성(extended attribute)의 지원과 POSIX 스타일의 억세스 콘트롤 방법이다.

일반적인 리눅스 시스템에서 ext2나 ext3 시스템을 사용한다. (ReiserFS가 세번째로 많이 쓰인다) 이들이 사용자들이 가장 많이 사용하는 시스템이기 때문에 개발 과정에서도 이들에 대한 개선 사항이 가장 많았다. 이들에 대한 가장 중요한 개선점은 확장속성(또는 메타데이타라고도 부른다)에 대한 지원이었다. 각각의 파일에 대한 속성들을 파일 시스템 내에 저장해 두는 것이다. 이들 속성 중 몇가지는 시스템이나 root 에 의해서만 읽고 쓸수 있도록 된다. 윈도우나 맥 OS와 같은 다른 운영체제들은 이미 이러한 기능을 사용하고 있다. 불행하게도 기존의 유닉스용 프로그램들은 이들 정보를 제대로 인식하거나 사용하지 못하는 경우가 많아 (tar등) 이들을 업데이트 해주지 않으면 안된다. 확장 속성이 이용된 가장 첫번째 분야는 POSIX 스타일의 억세스 콘트롤을 위한 부분이었다. 이것은 유닉스 스타일의 권한 체계보다 좀 더 확장되어 세밀한 권한 설정이 가능하도록 하는 시스템이다. ext3에 대한 이런 변화 말고도 몇가지 변화된 부분들이 있는데 저널링을 사용할 때 커밋(commit)시간을 전원 관리등을 설정해서 사용하는 노트북 유저들을 위해 튜닝될 수 있도록 수정되었다. 이 정보들은 파일 시스템 내에 저장되어 마운트 할 때마다 새로 지정해줄 필요가 없다. 그리고 디렉토리 내부의 파일 검색을 좀 더 빠르게 하기 위해 디렉토리가 인덱스 되었다는 표시를 해둘 수가 있다.

리눅스의 고전적 파일 시스템 이외에도 리눅스 커널은 XFS등과 같이 새로운 파일 시스템에 대한 지원도 포함한다. 이 파일 시스템은 Irix 시스템에서 기본으로 설정되는 XFS 파일 시스템에서 나온 것이고 블럭 레벨에서 호환성이 있다. ext3나 Reiser와 같이 루트 디스크에 쓰일 수 있고 확장 속성이나 ACL과 같은 새로운 기능들을 지원한다. 많은 배포본들이 리눅스 2.4 기반에 이 파일 시스템을 지원하기 시작했다. 하지만 어떤 파일 시스템이 최후의 승자가 될지는 아직 더 지켜봐야 할 것이다.

이외에도 리눅스는 파일 시스템 내부나 외부적으로 독점 운영체제와의 호환성을 개선시키기 위한 많은 개선사항이 있다. 우선 리눅스 2.6은 MS 윈도우의 논리 디스크 매니저(Logical Disk Manager)를 지원한다. 이것은 다이나믹 디스크라고 불리는 기능이다. 윈도우 2000이후 버전의 윈도우에서 파티션의 크기 조정을 자유롭게 하기 위해 새로 도입한 파티션 테이블 방식이다. (물론 리눅스 배포본에서 이 시스템을 사용할 것 같지는 않다) 리눅스 2.6은 또한 NTFS 파일 시스템에 대한 지원 부분을 완전히 재작성 하여 NTFS 볼륨에 대한 읽기 쓰기가 가능해졌다. (물론 쓰기에 대한 부분은 아직은 실험적이고 점진적으로 개선될 것이다.) 마지막으로 리눅스는 FAT12에 대한 지원 부분이 개선되어 몇몇 이 포맷을 사용하는 mp3 플레이어에 생기는 문제점들이 개선되었다. 확장속성 지원이 HPFS 파일 시스템에도 포함되었다. 이전 버전에서도 그랬지만 리눅스는 2.6에서도 다른 운영체제와 잘 섞여 사용할 수 있는 "스위스 군대 칼"과 같은 존재로서의 위상을 강화해 나가고 있다.

이들 변화 사항 말고도 리눅스 파일 시스템에 대한 많은 변화가 있었다. 할당량(Quota) 지원 부분이 좀 더 많은 사용자들을 지원하기 위해 재작성되었고, 각각의 디렉토리들이 동기적으로 동작할 수 있도록 개선되었다. (이것은 메일 시스템이나 디렉토리 기반의 데이타베이스 등의 시스템에 유용한데 디스크가 손상된 경우의 복구에 좋다) CD-ROM 등에 쓰이는 ISO9660 파일 시스템에서 투명한 압축이 지원되며 메모리 기반의 파일 시스템인 hugetlbfs가 새로 추가되어 공유 메모리 데이타베이스에 대한 지원이 강화되었다.

입출력 지원

대부분의 컴퓨터 시스템들은 외부와 연결될 때 그리 중요해 보이지 않는 입출력 장치로 연결된다. 이에는 마우스와 키보드, 사운드 카드, 비디오 카드, 조이스틱과 같은 디바이스들이 포함된다. 리눅스 2.6 개발 과정 중에 많은 기기들에 대한 지원이 추가되었지만 기본적인 디바이스들은 그 이전부터 이미 지원되어 왔고 이미 충분히 안정적이다. 외부 버스 지원과 Bluetooth 지원 등과 같은 부분의 개선 덕분에 디바이스들에 대한 지원이 확장되게 되었다. 많은 부분에서 큰 개선이 있었다.

HID(Human Interface Devices)

커널 2.6의 내부 변화중 가장 큰 것들 중 하나가 바로 휴먼 인터페이스 레이어가 재작성된 것이다. 휴먼 인터페이스 레이어는 리눅스 시스템에 대한 사용자들의 접점을 규정하는 가장 핵심이 되는 부분이다. 커널 새 버전에서는 이 레이어에 대해 이전 버전보다 더 큰 작업이 행해졌고 더 모듈화 되었다. 이제는 디스플레이와 같이 필수적이라고 생각했던 것들이 없어도 시스템 구성이 가능하다. 철저하게 모듈화 되어서 그렇다. 이런 모듈화의 가장 큰 장점은 임베디드 디바이스에 대한 개발이 손쉬워졌다는 것이다. 넣고 싶은 기기를 넣고 빼고 싶은 기기를 뺄 수 있으며 대신 네트웍이나 시리얼 포트를 통해서 제어한다던지 하는 일들이 가능해졌다. 하지만 사용자들의 측면에서는 다른 측면에서의 장점이 생긴다. 예를 들어 PC를 가지고 있다면 무조건 표준 AT(i8042)기반의 키보드가 있어야 한다던지 하는 기본 전제를 무시할 수 있게 된 것이다.

리눅스의 모니터 출력을 지원하는 부분에도 많은 변화가 있었다. 물론 커널 내부의 프레임버퍼 서브 시스템을 사용하는 경우에만 해당되는 경우가 대부분이지만. (인텔 기반의 리눅스 시스템들은 대부분 그렇지 못하다) 필자 개인적 의견으로는, 이 기능의 가장 좋은 점은 부팅 시에 귀여운 팽귄 로고가 24bpp의 해상도로도 지원될 수 있게 된 점이다. 그리고, 콘솔 자체도 리사이즈 되거나 회전할 수 있게 되었고(PDA등에서 유용할 것이다) 좀 더 많은 하드웨어를 지원한다. 마지막으로, 리눅스 커널에 VESA(Video Electronics Standard Association) 모니터들에 대해 그들의 기능에 대한 쿼리를 날릴 수 있다. 물론 이런 일들은 XFree86에서는 이미 하고 있던 일들이기는 하다.

이런 큰 변화점들 말고도 리눅스 2.6은 또한 사용자와 상호작용하는 측면에서 작은 변화들을 많이 포함하고 있다. 예를 들어, 터치 스크린이 이제 지원된다. 마우스와 키보드 드라이버들도 표준화 되어 동일한 디바이스 노드를 가지게 되었다.(예를 들어 마우스는 /dev/input/mouse0) 복잡한 마우스들(휠이 여러개라던가)도 이제 지원된다. PC 키보드 매핑에 대한 부분도 개선되어 표준 윈도우 키보드도 지원된다. XBox 게임패드등 조이스틱에 대한 지원도 많은 드라이버들이 나와주어서 상당히 개선되었다. 포스 피드백 지원도 포함되었다. 마지막으로, Tieman Voyager 브라이유(braille) 점자 TTY 디바이스에 대한 지원이 포함되었다. (이 기능은 리눅스 2.4에도 백포팅 되었을 정도로 중요한 기능이다)

한가지 덧붙이면, 리눅스에는 로컬 키보드를 갖지 않은 시스템을 위한 "시스템 리퀘스트(system request)"인터페이스에 작은 변화가 생겼다. 시스템 리퀘스트(sysrq) 인터페이스는 시스템 관리자가 콘솔에서 디버깅 정보를 얻고 시스템을 리부팅 하고 파일 시스템을 읽기 전용으로 마운트 해서 여러가지 일들을 할 수 있도록 만들어졌다. 리눅스 2.6에서 키보드 등이 없는 시스템을 지원하므로 이들 이벤트들을 /proc 파일 시스템을 통해 발생시키도록 할 수 있게 되었다. (물론 시스템이 멈추거나 한 경우에는 별 도움이 안되겠지만)

오디오 & 멀티미디어

리눅스 2.6으로 넘어오면서 사용자들이 가장 기다렸던 추가 기능 중 하나가 ALSA(Advanced Linux Sound Architecture)이다. 이전의 사운드 시스템인 OSS(Open Sound System)이 그동안 사용되어 왔지만 몇가지 구조적 제약사항들 때문에 대치되게 되었다. 첫번째 개선사항은 기반부터 철저하게 쓰레드와 SMP에 안전하도록 설계되었다는 점이다. 이전에는 데스크탑은 무조건 CPU를 하나만 갖는다는 가정 하에 동작하도록 되어 있었다. 더욱 중요한 점은 대단히 모듈화 되어 새로운 사운드 카드의 지원도 손쉬워 졌다는 점이다. 물론, 내부가 아름다와 졌다고 해도 외부에 보이는 기능 개선이 없다면 사용자 측면에서는 별 의미가 없을 것이다. 새로운 사운드 시스템은 상당히 많은 강력한 기능들을 가지고 있다. 가장 큰 기능들을 꼽아보면 새로운 사운드 디바이스(USB오디오나 MIDI디바이스)들에 대한 지원, 전이중(full-duplex) 재생과 녹음 기능, 하드웨어 믹싱, 사운드 디바이스들의 통합 작동 등등이다. 오디오 기능에 대한 매니아이건 MP3만 듣는 정도의 사용자이건 무척 환영할 만한 기능들이다.

간단한 오디오 재생뿐 아니라 근래의 사용자들이 원하는 기능들은 상당히 다양하다. 웹캠, 라디오 또는 TV 어댑터, 디지탈 비디오 레코더 등도 포함된다. 이 세가지 경우에 대해 리눅스 2.6에서의 지원이 개선되었다. 리눅스에서 이전에도 이미 라디오 카드나 TV 튜너, 비디오 카메라 등을 지원해왔으나 극히 최근의 일이다. Video4Linux(V4L)이라고 불리는 이 시스템에 많은 개선사항이 추가되어 최신버전에서는 API의 정리작업이 수행되었고 좀 더 많은 기능들이 추가되었다. 새로운 API는 이전 버전의 API와 호환되지 않아 이전 버전의 API를 사용하는 응용 프로그램은 새로 업그레이드 해야 한다. 또다른 특기사항을 리눅스 2.6에서는 디지탈 비디오 방송(DVB) 하드웨어에 대한 지원을 포함한다. 셋탑 박스 등에서 사용하는 이런 하드웨어는 리눅스 시스템을 Tivo와 같은 디바이스로 변신시킬 수 있는 기능을 제공한다.

소프트웨어 개선사항들

네트워킹

항상 최신의 네트워킹 지원이 리눅스의 가장 중요한 인기 포인트 중 하나였다. 리눅스는 이미 TCP/IP(v4 & v6), Apple Talk, IPX등과 같이 가장 인기있는 네트웍 프로토콜들을 지원한다. (지원하지 않는 것들 중에는 NetBEUI같은것도 있기는 하다) 다른 서브 시스템들의 변화와 마찬가지로 네트웍 하드웨어에 대한 변화들은 지극히 내부의 일이고 겉에서는 잘 알아차리기 힘들다. 하부 구조들은 디바이스 모델과 디바이스 드라이버들이 새로이 업데이트 된데에서 많은 장점을 얻었다. 예를 들어, 리눅스는 현재 여러 네트웍 디바이스 드라이버들이 사용하던 MII(Media Independent Interface 또는 IEEE802.3u) 서브 시스템을 가지게 되었다. 이 새로운 서브 시스템은 각각의 디바이스들이 조금씩 다르게 다루던 부분들을 모두 수정하게 된다. 다른 변화들은 ISDN 업데이트와 같은 것들이 있다.

소프트웨어 측면에서 가장 큰 변화중 하나는 IPsec 프로토콜의 지원이다. IPsec 또는 IP Security라는 프로토콜은 IPv4와 IPv6에서 네트웍 프로토콜 레벨에서 암호화 보안을 사용 가능하게 해주는 프로토콜의 집합이다. 보안 기능이 프로토콜 레벨에 들어가기 때문에 응용 프로그램들에서는 이것들을 의식해서 새로 작성하거나 할 필요가 없다. 이것은 SSL이나 터널링/보안 프로토콜과 동일한 개념이지만 그보다 좀 더 저수준이다. 현재 커널에서 지원하는 암호화는 SHA(Secure Hash Algorithm)나 DES(Data Encryption Standard)등을 포함한다.

프로토콜의 다른 부분에서는 리눅스는 멀티 캐스트 네트워킹에 대한 지원이 강화되었다. 멀티캐스트 네트웍은 한개의 패킷을 보내면 여러 대의 컴퓨터에서 그 패킷을 받게 되어 있는 네트웍이다. (기존의 포인트-투-포인트 방식의 네트웍과 비교해 생각해보라) 이는 Tibco와 같은 메시징 시스템이나 오디오/비디오 컨퍼런스 소프트웨어에 사용된다. 리눅스 2.6은 MLDv2(Multicast Listener Discovery)와 IGMP3(Internet Group Messaging Protocol)과 같은 몇가지의 SSM(Source Specific Multicast) 프로토콜들을 지원한다. 이들은 Cisco와 같은 하드웨어 네트워킹 벤더들에 의해 지원되는 표준 프로토콜 들이다.

리눅스 2.6은 또한 LLC 스택을 분리구현했다. LLC는 Logical Link Control 프로토콜(IEEE 802.2)인데 NETBeUI나 IPX, Appletalk과 같은 몇몇 일반적인 고수준의 네트웍 프로토콜의 기반을 이루는 저수준 프로토콜이다. 변화의 일부로는 IPX, Appletalk, 토큰 링 드라이버들이 새 서브시스템의 이득을 보기 위해 새로이 작성되었다. 외부 프로젝트로 NetBEUI 프로토콜 스택을 작성하는 프로젝트가 진행되고 있는데 이것이 커널 내부로 병합될지는 두고 봐야 할 것이다.

이것들 이외에도 작은 변화들이 상당히 많다. IPv6에 많은 변화들이 가해졌고 토큰 링 네트워크에서도 동작하게 되었다. 리눅스의 NAT/masquerading 지원은 다중 접속을 필요로 하는 프로토콜들(H.323, PPTP등)에 대해서도 잘 지원하도록 수정되었다. 리눅스에서 VLAN을 설치하는 것은 이제는 더 이상 "실험적"이라고 할 수 없다.

네트웍 파일 시스템

리눅스의 유연한 네트웍 프로토콜 지원의 상단에는 역시나 유연한 네트웍 파일 시스템 지원이 존재한다. 네트웍 파일 시스템을 노출(export)하고 마운팅하는 것은 커널이 직접 관리하는 고수준의 네트웍 동작이다. (역시 비슷하게 응용 프로그램에서 파일처럼 사용하게 되는 네트웍 블록 디바이스들은 2.6에서 그리 큰 변화가 있지 않았다) 그외의 네트웍 동작들은 대부분 사용자 스페이스로 밀려갔고 커널 개발자들의 영역에서 다소 멀어졌다.

리눅스와 유닉스 호환 운영체제의 세계에서 가장 중요한 네트웍 파일 시스템은 NFS(Network File System)이다. NFS는 매우 복잡한 파일 공유 프로토콜이며 유닉스에 깊은 뿌리를 박고 있는 파일 시스템이다 (특히나 썬의 솔라리스에서의 구현은 더 그렇다) NFS는 TCP나 UDP등을 사용할 수 있지만 몇가지 별도의 RPC(Remote Procedure Call)를 기반으로 동작하는 서브 프로토콜들도 필요로 한다. 이것들은 인증을 위한 "mount" 프로토콜과 파일 록킹을 위한 NLM(Network Lock Manager)등을 포함한다. (일반적인 구현 버전들은 대부분 또다른 RPC 기반의 프로토콜인 NIS에 인증등의 기능을 의지한다. NIS와 그 비슷한 것들은 보안상 그리 안정적이지는 않기 때문에 리눅스 머신에서는 일반적으로 많이 쓰이지는 않는다) NFS가 널리 쓰이는 인터넷 프로토콜의 위치를 차지하지 못한 것은 그 복잡함 때문일 것이다.

리눅스 2.6에서는 NFS는 많은 개선이 있었다. 가장 큰 개선이라면 서버나 클라이언트에 새로운 NFSv4 프로토콜을 실험적으로 지원한다는 것이다. (이전 버전의 리눅스에서는 v2나 v3만 지원했었다) 새 버전은 좀 더 강력하고 안전한 암호에 기반한 인증을 지원하며 좀 더 지능적인 록킹(locking)과 가짜 파일 시스템(pseudo-filesystem)을 지원한다. NFSv4의 모든 기능이 아직 구현되지는 않았지만 지원 자체가 제법 안정적이어서 중요한 서버에서도 사용될 수 있을 만큼의 안정성을 보인다. 추가적으로 리눅스의 NFS서버 구현은 좀 더 확장성 있게 설계되었다 (64배 더 많은 동시 사용자와 더 큰 요청 큐를 가진다). 그리고 좀 더 완전하고(TCP와 UDP상에서 동작), 좀 더 유연하며, 좀 더 쉽게 유지보수가 가능하다. (시스템 콜이 아닌 nfsd 파일 시스템을 통해서 가능하다) 별도로 분리된 lockd와 nfsd, 지원되는 인터페이스에 대한 zero-copy 네트워킹 등의 숨겨진 변화들도 많다. NFS는 시스템 관리자가 커널의 lockd 포트 번호를 할당할 수 있도록 하여 비교적 손쉽게 보안을 강화할 수 있도록 하였다. NFS 클라이언트 사이드는 또한 캐쉬 구조와 UDP를 통한 연결 콘트롤, 기타 TCP에 가해진 개선사항등 하부의 RPC 프로토콜에서 이득을 본다. 리눅스에서 NFS 볼륨을 루트 파일 시스템으로 사용하는 것은 (디스크 없는 시스템과 같이) TCP 상의 NFS가 지원되도록 개선되어 가능하도록 되었다.

이와 같은 유닉스 스타일의 네트웍 파일 시스템 이외에도 리눅스 2.6에서는 윈도우 스타일의 네트웍 파일 시스템에 대해서도 많은 개선이 있었다. 윈도우 서버군에서 표준으로 사용하는 공유 파일 시스템인 SMB 프로토콜에 대한 지원이 더 강화되었다. 물론 윈도우 2000에서는 SMB 프로토콜보다 좀 더 개선된 버전인 CIFS(Common Internet Filesystem)이라는 것이 표준화 되었다. 이 업그레이드는 프로토콜 자체가 특정 시점에 엉망이 되는 것을 막고 좀 더 잘 동작하도록 하는데 목표가 있다. (프로토콜 자체가 많이 개량되어 결국 어떤 시점에서부터 윈도우 NT나 윈도우 2000과 윈도우 95/98/ME와 호환이 되지 않게 되었다) CIFS는 그 목적 이외에도 유니코드 지원, 파일 록킹 기능 개선, 하드 링크, NetBIOS에 대한 의존성 제거, 그리고 윈도우 사용자들을 위한 몇몇 기능 개선이 추가되었다. 그래서 한동안 리눅스 사용자들은 CIFS와 제대로 공유할 수 없었으나 리눅스 2.6부터는 CIFS에 대한 지원이 완전히 재 작성되어 완벽하게 호환이 된다. 리눅스 2.6에는 SMB와 CIFS 프로토콜의 확장인 SMB-UNIX 익스텐션에 대한 지원이 추가되어 Samba와 같은 SMB서버에 윈도우 파일 타입이 아닌 파일 타입(디바이스 노드나 심볼릭 링크 등)을 지원할 수 있게 되었다. 근래에는 드물게 리눅스는 노벨 넷웨어에 대한 지원도 빼먹지 않았다. 리눅스 2.6에서는 내장된 NCP(Netware Core Protocol) 파일 시스템 드라이버를 통해 256개 까지의 공유를 마운트 할 수 있다.

리눅스 2.6은 하나의 로지컬 볼륨에 존재하는 파일들이 여러개의 노드들에 분산되어 있을 수 있는 비교적 새로운 종류의 분산 네트워크 파일 시스템을 지원한다. 리눅스 2.4에서 지원이 시작된 CODA 파일 시스템 이외에도 AFS와 InterMezzo에 대한 지원이 추가되었다. AFS는 Andrew Filesystem(CMU에서 개발되어 이름이 저렇다)은 아직은 매우 제한적이고 읽기 전용으로 밖에 동작하지 않는다. 두번째 새로 지원되는 파일 시스템인 InterMezzo(역시 CMU에서 개발되었다)는 리눅스 2.6에서 지원되기 시작했는데 비접속 기능(로컬에서 동작하도록 하는)과 같은 높은 수준의 기능들의 동작이 가능하며 반드시 디스크의 공간이 존재해야만 하는 종류들의 응용 프로그램에 사용될 수 있다. 물론 여러대의 시스템, 노트북이나 PDA 또는 데스크탑 컴퓨터 등에서 서로의 파일 내용을 싱크할 수 있는 기능도 내장되어 있다. 새로운 파일 시스템을 지원하기 위한 프로젝트들이 존재한다.

기타 기능들

보안

리눅스 2.6에서 새로 부각된 부분이지만 주목을 많이 못받고 있는 분야가 보안 관련 분야이다. 가장 기본적으로 근래에는 커널 기반의 보안(유닉스에서의 root 사용자의 권한) 자체도 모듈화 되어서 여러가지 보안 모델 중 하나가 되어 버렸다. (어쨌거나 현재까지 기본적으로 제공되는 모델이고 새로운 모델에 대해서는 어떻게 만들 수 있는지 보여주는 것에 불과하다) 이런 변화중 하나로 커널의 모든 부분이 대단히 세부적인 억세스 콘트롤 기반을 기초로 사용하도록 수정되었다. 물론 대부분의 리눅스 시스템들은 이러한 root 기반의 보안 모델을 계속 사용하겠지만 이런 기본적인 부분들이 없이도 시스템이 구성될 수 있다. 또 다른 보안 관련 변화 중 하나는 바이너리 모듈(하드웨어 개발 업체에서 제공하는 드라이버와 같은)들이 더 이상 시스템의 시스템 콜 테이블을 수정하여 시스템 콜을 오버로딩할 수 없도록 수정되었다는 점이다. 이것은 오픈 소스가 아닌 모듈들이 커널이나 기타 GPL 기반의 소프트웨어에 보안상의 헛점을 만드는 것을 더 이상 용납하지 않는다는 점에서 보안이 한층 강화됨을 뜻한다. 또 하나의 보안 관련 변화 사항은 리눅스 커널이 이전에 사용되던 하드웨어 변동에 기반한 엔트로피 풀 방식의 랜덤 넘버 제네레이터 대신 하드웨어 랜덤 넘버 제네레이터를 사용할 수 있게 되었다는 것이다. (몇몇 프로세서에 내장되기 시작했다)

리눅스의 가상화

리눅스 2.6의 가장 재미있는 새 기능중 하나는 유저 모드(user-mode) 아키텍쳐를 채용하기 시작했다는 것이다. 이것은 리눅스를 리눅스 자체로 포팅해서 리눅스 상에서 리눅스가 실행된다는 의미이다. 리눅스의 새 인스턴스는 완전히 보통의 응용 프로그램인 것 처럼 실행되게 된다. 응용 프로그램 내부에서 가짜 네트웍 인터페이스나 파일 시스템, 호스트의 디바이스와 통신하도록 만들어진 특수한 디바이스 드라이버를 통해 디바이스를 지원할 수 있게 된다. 이것은 (profiling등) 개발을 위해서나 보안 분석을 위해서 대단히 바람직한 것으로 밝혀졌다. 물론 상당수의 사용자들은 이런 기능을 필요로 하지 않겠지만 대단히 멋진 기능임에 틀림이 없다. (친구들을 감동시켜 보라!)

랩탑 지원

앞서 이야기 한 일반적인 지원들(APM, ACPI, 무선 네트웍 지원등) 이외에도 리눅스는 랩탑 사용자들을 위해 두가지의 분류하기 어렵지만 유용한 새로운 기능들을 제공한다. 첫번째는 소프트웨어 서스펜드 기능 기능(software-suspend-to-disk)이다. 아직은 약간의 버그가 남아 있지만 많은 경우 별다른 문제 없이 사용이 가능한 수준이다. 또 하나의 기능은 시스템 전원이 연결 되어 있는지 여부에 따라 프로세서의 속도를 자동으로 바꾸어 주는 기능이다.

설정 관리(Configuration Management)

리눅스 2.6은 몇몇 작은 기능 개선을 가지고 있다. 주로 개발자들이 커널의 문제에 대해 디버깅을 할 때 큰 도움을 받을 기능이지만 여러대의 서버를 관리해야 하는 관리자들을 위해서도 유용한 기능이다. 간단하게 이야기 해서 커널에 커널 파일 자체의 설정 파일을 내장시킬 수 있다. 여기에는 커널 설정의 각종 옵션들에 대한 정보들이 함께 기록되며, 어떤 컴파일러가 사용되었는지와 기타 동일한 커널을 컴파일 하기 위해 필요한 여러 환경들을 담고 있다. 이 정보들은 /proc 인터페이스를 통해 살펴볼 수 있다.

기존 응용 프로그램 지원

리눅스 커널 2.6이 메이저 업그레이드이긴 하나 사용자 응용 프로그램에서 변화시켜야 할 부분의 거의 없는 것이나 마찬가지이다. 하나의 예외는 쓰레딩에 대한 부분이다. 어떤 응용 프로그램들은 2.4나 2.2에서는 허용되었으나 그 이후에는 허용되지 않는 작업을 하는 경우가 있을 수 있다. 이것들은 어쨌거나 예외적으로 취급해야 한다. 물론 모듈 유틸리티와 같은 저수준에서 동작하는 프로그램들도 동작하지 않을 것이다. 추가적으로, /proc과 /dev에 존재하는 몇몇 파일들과 그 형식이 변화되어 여기에 의존적으로 작성된 응용 프로그램들은 제대로 동작하지 않을 가능성이 있다. (새로운 /sys 버추얼 파일 시스템으로 많은 부분들이 옮겨져서 그렇기도 하다. 호환성을 위해서 /dev 디바이스 이름들도 쉽게 설정할 수 있기는 하다)

이런 것들에 추가적으로 많은 부분이 변경되었다. 첫번째로 리눅스 2.0 이나 그 이전에 만들어진 스왑 파일들은 새로 포맷을 해야 한다. (스왑 파일에는 별다른 중요한 내용이 저장되지는 않기 때문에 대부분의 경우 문제가 되지는 않을 것이다) 아파치나 Zeus등의 웹서버들이 커널 수준의 속도에 접근 할 수 없도록 막는 병목이 제거 되었으므로 커널이 웹 페이지를 직접 서비스 할 수 있는 kHTTPd 데몬이 제거 되었다. Dos/윈도우에서 대용량 하드디스크의 사용을 위한 OnTrack이나 EzDrive등의 디스크 매니저에 대한 자동 감지 기능이 제거 되었다. 마지막으로 플로피 디스크에서 부팅을 하기 위한 특수한 형태의 커널 부트 섹터가 제거되었다. 이제는 SysLinux를 사용해야 한다.

마치며

이 문서는 BitKeeper의 changelog와 소스 여기 저기를 뒤져보고 메일링 리스트의 내용들을 검토하고 Google과 Lycos의 검색 결과를 이리저리 뒤져보아서 작성한 문서이다. 그래서 혹시 잘못된 내용이 포함되어 있거나 중요한 내용이 빠져있거나 필자가 오해하고 있는 부분이 있을 수 있다. 혹시라도 잘못된 내용을 찾게 된다면 필자의 이메일인 jpranevich at kniggit.net 으로 메일을 보내어 수정해주기 바란다.

이 문서의 새 버전은 항상 http://kniggit.net/wwol26.html 에 올려놓고 있다.

번역

이 문서는 영어 이외에도 아래와 같이 여러가지 언어로 번역되어 있다.

• 불가리어 -
  공유하기

  게시글 관리

  구독하기Tornado 의 블로그

  'OS > LINUX' 카테고리의 다른 글

  [펌] ☞ anonymous ftp 막기  (0)	2004.06.10
  [펌] ☞ root 접속제한  (0)	2004.06.10
  [linux] hostname 바꾸기..  (0)	2004.06.08
  [펌] Nmap 네트워크 점검 도구 및 보안 스캐너 3  (0)	2004.06.04
  [펌] Nmap 네트워크 점검 도구 및 보안 스캐너 2  (0)	2004.06.04