이만용 yong@linuxkorea.co.kr
|
|||||||
커널 2.2를 기다리며... 리눅스 커널 안정 버전은 현재 공식적으로 2.0.33 이다. 거의 공식적인 것이나 다름없는 32 프리(pre) 패치는 앨런 콕스(Alan Cox)씨에 의해 관리되고 있으며, 이것도 약 10회 이상 나와 있어 조만간(?) 2.0.34 버전으로 올라가게 될 것이다. 바로 이전 안정 커널인 1.2 의 경우 수많은 버그와 개선점들이 남아 있음에도 불구하고 13번의 패치 레벨에 그쳤고 1.3개발 버전에 모든 정력을 쏟느라 상대적으로 방치(?)되었다는 지적을 듣게 되었는데 이번에는 오히려 안정버전이라는 이름의 커널이 무려 33 번이나 패치를 가해 도대체 33번이나 패치를 해야 하는 것이 안정 버전이라고 부를 수 있는가라는 일부의 비판을 받기도 한다. 커널 1.2 버전에 대한 관리 방식에 대한 반성이 너무 지나쳤던 것일까? 어찌 되었든 거의 2년에 가까운 개발버전 2.1의 진행 과정 속에서도 안정버전 2.0 에 대한 관리를 소홀히 하지 않으려고 리누스와 수 많은 커널 개발자들이 노력하였다고 생각한다. 판단은 여러분이 직접 개발 버전 2.1을 사용해보거나 2.2을 사용할 때 내려질 것이다. 리눅스 사용인구가 급증하면서 이제는 모든 사용자가 예전처럼 새로운 개발 버전이 나왔다고 재미 삼아 컴파일하는 시대가 아니다. 여전히 많은 리눅서들이 신버전에 열광하기도 하지만 셧다운을 허용하지 않는 실전의 리눅스 서버들은 안정 버전만을 요구하고 있기 때문이다. 레드햇 리눅스, 데비안 리눅스의 경우 커널 2.0의 모듈 기능을 십분 활용하고 있기 때문에 특별한 경우가 아니고서는 설치 직후 커널 컴파일을 다시 해 줄 필요가 없다(물론 컴파일을 해주면 486 이상의 시스템에서 더욱 최적화되어 돌아간다.). 동호회 게시판을 둘러보아도 옛날처럼 '커널 컴파일 광'들은 많지 않은 것 같다. 리눅스 커널 컴파일을 몇 번 성공해보면 그것처럼 재미있는 일도 없지만 요즘에는 커널말고도 수없이 많은 오픈 소프트웨어들이 나오고 있기 때문이기도 하다. 재미있는 일들이 훨씬 많이 생겨나고 있는 것은 분명한 사실이다. 넷스케이프 브라우저 소스 공개 이후에는 그 동안 생각지도 못했던 모질라(Mozilla)를 컴파일해 볼 수 있지 않은가? 2년간 세상이 참 많이 변했다. 몇 번의 새로운 배포판들이 나오고 한글 판을 제작하다보니 벌써 2년이 훌쩍 지나갔다. 그 사이 개발 버전 커널의 버전은 현재 2.1.102에 이르렀다. 리눅스의 아버지이며 현재에도 커널 관리자인 리누스에게도 많은 일들이 일어난 세월이다. 핀란드에서 미국 캘리포니아로 이사하여 트렌스메타(Transmeta)라는 회사에 입사하였고 벌써 리누스 버전 2.0, 3.0 이렇게 두 딸의 아버지가 된 상태이다. 리눅스의 마스코트인 앉아있는 펭귄처럼 배가 나온 아저씨가 되가고 있다. 이제 패기만 충천한 청년이라고 보기에는 힘들다. 리눅스와 함께 한 시간이 이미 7년이 되어가고 있으며 그 많은 경험 속에서 더욱더 전세계 리눅서들의 신뢰와 사랑을 받을 수 있는 어른이 되어있다. 지금은 기저귀 속에 파묻혀 어려운 관리 작을 하고 있겠지만 얼마 전 '개발 버전 2.1 종결'을 선언하고 새로운 안정버전 2.2를 내기 위해 더욱 열심히 일하고 있을 리누스와 수많은 커널 해커들에게 박수를 보낸다. 그들이 밤새워가며 가꿔온 커널 2.1 버전에 대한 간략한 분석을 해보고 언제 발표될지 모르는 새로운 안정 커널 2.2를 기대해 보자.
커널 2.1 의 전체적인 특징 리눅스 커널 2.1은 커널 2.0에비해 정말 방대해졌다. 비교할 수 없을 정도로 많은 하드웨어가 지원되고 있다. 비교할 수 없을 정도로 많은 하드웨어가 지원되고 있다. 당연히 커널 소스가 방대해 질 수밖에 없다. 일부 파일(특히 텍스트 파일)에 대하여 gzip 보다도 엄청난 압축률을 자랑하는 bzip2 프로그램으로 압축된 tar.bz2 파일이 제공되고 있다. 기존의 tar.gz 보다 2메가 정도 적은 용량의 파일을 다운로드 받을 수 있다. 리눅스 커널의 장점인 모듈 기능이 철저하게 구현되어 왔다. 따라서 초소형 커널을 구축하기 쉽다. 예를 들어 하드웨어 사양이 매우 빈약한 내장 시스템에서 사용될 수 있도록 되어 있다. 특히 사운드 기능이 획기적으로 모듈화되어 제공된다. 무엇보다도 커널 2.1.4? 대 근처에서 커널의 중요 루틴을 개선하여 속도를 많이 개선하였다고 하니 기쁜 소식이라 하지 않을 수 없다. 초고속 대용량 시스템에 사용될 수 있도록 SMP(대칭형 다중 프로세서) 기능이 인텔 버전의 경우 매우 안정적으로 작동할 것이라 예상하고 있다. 2.1 개발 커널의 초기 중요 이슈는 바로 SMP 의 완벽한 지원이었으며 핵심적인 노력이 가해졌으니 크게 기대해도 좋을 듯 하다. 2, 4개 이상의 CPU 위에서 안정적으로 돌아가는 고속 리눅스 박스를 보는 일은 정말 흐뭇한 일이지 않겠는가? 덧붙여 초고속 프로세서인 알파 프로세서에 대한 SMP 기능도 이제 서서히 시작된다고 하니 리눅스는 아직도 쉴 마음이 없는 듯 하다. 커널 2.1 중반부터 고속 파일 시스템을 위한 대대적인 개편작업이 진행되어 한 때 엄청나게 불안정한 파일 시스템을 제공했지만 지금은 거의 모든 심각한 수준의 버그가 고쳐졌다고 생각된다. 시스템의 속도에 있어 파일 시스템은 매우 큰 결정 요소이다. 정확한 벤치마킹을 해봐야겠지만 전체적으로 개발 버전 2.1은 2.0 보다 속도감 있게 시스템을 사용하고 있다고 본다. 하지만 PnP 기능 면에 있어서는 리누스나 다른 개발자들이 어떤 결정을 하고 있는지 모르겠으나 다소 불만족스럽다.
커널 2.1 컴파일 옵션 둘러보기
우선 알아두어야 할 것! 알파 테스트 수준의 기능을 선택할 것인가 말 것인가? 맨 처음 나오는 코드 성숙도 옵션(Code maturity level options)을 선택하는가 하지 않는가에 따라 이후에 선택할 수 있는 커널 기능의 폭이 결정된다. 여러분도 잘 알다시피 리눅스는 리눅스 소비자의 눈치를 보지 않는다. 리눅스는 소비자 전체가 테스터이기 때문에 불완전한 기능을 감추지 않고 그대로 제시한다. 이렇게 함으로써 소비자 중 능력이 있고 의지가 있는 사람이 나타나 기능을 개선하길 기대하기 때문이다. 리눅스의 모든 기능은 항상 진행형인 상태에 놓여 있다고 말 할 수 있다. 독자 중 일부는 이 말 때문에 리눅스가 다른 유닉스나 윈도우즈 NT 보다 불안하다고 느낄지 모른다. 버그가 있다는 것을 공식적으로 발표하지 않는다고 해서 버그가 없는 것은 아니다. 마이크로 소프트사의 홈피이지에 가보면 대대적으로 선전하지는 않는다 하더라도 수많은 서비스(?) 팩과 핫픽스를 다운로드 받을 수 있다. 그것을 다 받았다고 버그가 모두 사라졌다고 생각할 수 있을까? 리눅스에 포함되어 있는 많은 기능 중에서 특히 오랜 기간 많은 사람의 검증을 거치지 않은 코드도 있다. 이런 상태의 기능을 베타 단계의 전 단계인 알파 단계이라고 부른다. 앞으로 커널을 설정하면서 만나게 될 EXPERIMENTAL 이라고 표시되어 있는 것들이 바로 알파 단계의 기능이다. 알파 단계의 기능이 제대로 작동하지 않는다고 게시판이나 뉴스 그룹에 항의하는 것은 예의가 아니다. 자신의 환경에서는 제대로 작동하지 않을 때, 다른 사람과 개발자들을 위해 친절하게 버그 보고를 해주길 바라는 단계의 기능들이라는 점을 명심하자. 필자의 개인적인 경험상 실험적인 코드라고 되어있는 기능일수록 재미있는 것이 더 많고 실제로 많은 것들이 제대로 작동하는 것을 보았다. 코드 성숙도 선택화면에서 알파 단계의 코드/드라이버를 선택한 경우에만 나타나는 옵션에 대해서는 뒤에 ※ 문자를 표기하겠다.
개발 버전의 기본 설정은 SMP 가능 /usr/src/linux/Makefile 의 앞 부분은 다음처럼
되어 있다.
리누스와 개발자들은 인텔 플랫폼에서의 SMP 문제를 집중적으로 공략하기 위해 아예 개발 버전 2.1 은 기본 설정을 SMP 가능 상태로 해놓고 시작했다. SMP 기능을 확실하게 구현하겠다는 의지의 표현이기도 하다. CPU 가 한 개인 대부분의 시스템에서도 SMP=1
인 상태로 컴파일하여 사용할 수 있다. CPU가 한 개인 시스템을
SMP 시스템 중 특별한 경우로 처리해 버리기 때문에 SMP 커널을
사용해도 아무 문제가 일어나지 않는 수준까지 끌어올렸다.
Documetation/Changes 파일 꼼꼼히 읽기 이 파일 안에는 현재의 커널을 성공적으로 컴파일하기 위해 필요한 최소 조건에 대한 자세한 안내 글이 적혀 있다. 예를 들어 개발 버전 최신 버전에서는 PPP 패키지를 가장 최신 버전으로 사용해야 한다. 그렇지 않으면 PPP 기능을 사용할 수 없는 상태가 된다. 이 사실을 모르고 무턱대고 커널의 버그라고 말해서는 안 된다. 필자의 경우에는 알짜 레드햇 5(패치맨Ⅱ) 시스템을 그대로 사용하였다. glibc-2 시스템이므로 파일 안에서 말하고 있는 libc5 라이브러리 문제는 해당되지 않는다. 유일하게 pppd 패키지는 www.linuxhq.com에서 읽은 꽁수를 가지고 다시 컴파일하지 않고도 잘 사용하고 있다.
프로세서 타입 및 기능 선택 리눅스 커널은 인텔 오리지널 CPU를 잘 지워한다. 몇 가지 문제점을 드러내기도 했지만 발견되기만 하면 신속하게 고쳐져 왔기 때문에 AMD 또는 사이릭스와 같은 인텔 호환 칩도 잘 지원한다. 하지만 호환 칩을 사용하고 있다는 자부심을 갖고 있는 사람들은 리눅스 커널이 CPU 제품명을 대충 인텔 호환이라고 간단히 처리하는데 기분이 나빴을 것이다. 이제는 프로세서 선택 화면에서 호환 칩 목록을 볼 수 있으며 커널 부팅 시 깔끔하게 여러분의 CPU를 인식하여 보여준다.
프로세서 집합(Processor family)
아직 커널 프로세스 타입 선택 항목에 나와있지는 않지만 펜티엄Ⅱ 에서도 리눅스가 잘 지원되고 있으니 걱정하지 말라. DEC/알파 아키텍쳐에 있어서는 커널 2.0에 비해 획기적으로 많은 시스템을 지원하고 있다. 알파/리눅스에서 커널 2.0을 사용하는 경우에는 디지털사의 FTP 사이트(ftp.digital.com)에서 별도의 알파 리눅스용 커널 패치 파일을 가져와야 했으나 커널 2.1에는 거의 모드 들어있기 때문에 인텔/리눅스에서처럼 커널 소스를 그대로 가져와서 즉시 컴파일할 수 있다.
MTRR(Memory Type Range Register) 인텔 펜티엄 프로/펜티엄 Ⅱ 프로세서에서는 MTRR(메모리 유형 범위 레지스터)를 사용하여 프로세스가 접근하는 메모리 범위를 제어할 수 있도록 되어 있다. PCI/AGP 버스에 꽂힌 VGA카드의 동작 속도가 약 2.5 배 정도 빨라질 수 있다고 한다. 하지만 X 서버 자체가 이것을 잘 활용해야 효과가 있는 것이다. 조만간 XFree86 팀 또는 S.u.S.E. 리눅스 배포판 팀에서 MTRR 기능을 이용하는 새로운 버전의 X 서버를 발표하기를 기다리면 된다. 일부 SMP BIOS 에서는 부팅에 사용되는 첫 번째 프로세서에서만 MTRR을 설정하는 버그가 있기 때문에 시스템이 부팅 중 멈춰 버릴 수 있으니 주의하라.
동적 모듈 지원 더 이상 kerneld는 필요없다! 대신 kmod가 있다! 개발 버전 2.1 의 긴 기간 동안 모듈 기능에 대한 수많은 개선이 이뤄졌다고 한다. 자원을 효율적으로 사용하는데 있어 모듈 개념은 리눅스에 있어 매우 핵심적이기 때문이다. 윈도우즈 NT의 경우 사소한 하드웨어 드라이버 하나 추가하는 것만으로도 시스템을 리부팅해야 하는 것과 달리 리눅스는 커널 버전을 바꾸는 것만 제외하고는 리부팅하지 않고도 원하는 드라이버를 추가하고 빼낼 수 있다. 우스개 소리로 윈도우즈 NT 가 무정지 시스템에 사용될 수 없는 이유는 특유의 불안정성보다 매번 요구해오는 리부팅 때문이 아닌가? :) 모듈은 사용자가 직접 insmod 또는 modprobe 명령으로 적재할 수도 있지만 거의 대부분이 일은커녕 데몬(kerneld)이라는 특별한 프로세스가 자동으로 처리해 준다. 만약 시스템이 프린팅을 해야 하는데 프린터 드라이버가 없다면 커널 데몬이 알아서 올려준다. 프린팅이 끝나고 일정 기간 사용하지 않고 있다는 사실을 감지하면 다시 메모리에서 내려 놓는다. 리눅스에 익숙한 사람들은 이 사실을 잘 알고 있다. 그런데 최신의 개발 버전 2.1 에서는 더 이상 kerneld 라는 프로그램이 필요치 않다. 조금 어려운 기술적 용어를 사용하자면 사용자 영역(user space)에서 실행되는 kerneld의 역할을 커널 영역(kerneld space)의 kmod 라는 프로세스가 대신 하게 되었다. 따라서 개발 버전 2.1 최신 버전과 앞으로 나올 2.2 버전에서는 kerneld를 실행시킬 필요가 없다. 개발 버전으로 부팅한 후 kerneld를 죽여보라. 여전히 자동모듈로 로딩이 이뤄질 것이다. ps 명령으로 확인해보면 kmod라는 프로세스가 있다는 것을 발견할 수 있다.
일반적인 설정 PCI 지원 PCI BIOS 지원 PCI 버스에 대한 지원이 훨씬 개선 되었다. PCI BIOS 지원을 설정하면 PCI 장치 정보를 알아내기 위해 리눅스가 PCI BIOS를 사용한다. 일부 하드웨어적으로 결함이 있는 보드에서는 PCI BIOS를 사용하지 않고 PCI 직접 접근(PCI direct access support)을 선택해야 한다. PCI 직접 접근 지원(PCI direct access support) PCI BIOS를 사용하지 않을 때(예를 들어 자그마한 내장 시스템에서는 BIOS 자체가 없는 경우도 있다.), 또는 리눅스가 어떤 이유로 인해 PCI BIOS를 사용할 수 없을 때는 PCI 장치를 직접 접근한다. BIOS 지원과 직접 접근 지원을 둘 다 설정하면 BIOS 이용 방법이 우선권을 갖는다. PCI 이상 동작 해결(PCI quirks) BIOS 에 문제가 있는 경우에는 PCI 버스를 잘못 설정하거나 최적의 상태로 만들지 못하는 경우가 발생한다. 이 때 리눅스 자신이 문제를 해결하게 만드는 옵션이다. 대충 모르면 Y라고 해도 별 문제없다. PCI 브릿지 최적화(PCI brige optimization (experimental)) PCI 버스 시스템을 쓰고 있으면서도 BIOS 가 제대로 작동하지 않는 시스템에서 몇몇 하드웨어 장치의 접근 속도를 향상시켜 줄 수 있는 옵션이다. 여러분에게 도움이 된다고 생각할 때만 Y를 선택한다. 보통은 N이다. 전 버전과 호환되는 형식의/proc/pci 개발 버전에서 /proc/pci라는 파일은 없다. 대신 /proc/bus 디렉토리 밑에 pci라는 별도의 디렉토리가 생긴다. 이전 버전과 호환되는 형식의 /proc/pci 파일을 원할 때만 Y라고 적는다. cat으로 보면 PCI 장치명을 확인할 수 있는 파일이었다.
MCA 지원 마이크로채널 아키텍쳐는 IBM PS/2 머신 또는 랩탑 일부에서 사용하고 있는 버스 시스템이다. 아마도 MCA 버스를 가지고 있는 경우는 거의 없을 것이다. 자세한 내용은 문서 디렉토리(linux/Documentation)에 있는 mca.txt를 읽어 보라.
BSD 프로세스 회계 기능 이 기능을 커널 안에 넣어두고 특별한 사용자 영역의 프로그램을 사용하면 프로세스에 대한 자세한 정보를 파일에 기록 해 둘 수 있다. 특별한 시스템 호출을 사용하여 커널에게 통보해주면 커널은 프로세스가 존재할 때마다 생성 시기, 소유권자, 명령 이름, 메모리 사용현황, 제어 터미널 정보 등을 파일에 추가한다. 특별한 통계 프로그램을 사용하여 이 정보를 유용하게 사용할 수 있다. 사용자들이 어떤 명령을 사용하고 있으며 시스템에 얼마만큼의 부하를 주고 있는지 통계를 낼 수 있도록 해준다. 일반적으로 Y라고 해두는 것이 좋다.
Sysctl 지원 리눅스는 모듈 기능 등 커널의 거의 모든 기능을 리부팅 없이도 그때그때 필요에 따라 동적으로 변화하고 적용 시킬 수 있는 방향으로 개발되어 왔다. 무정지 시스템에서 불필요한 리부팅을 막을 수 있어야 한다는 것은 분명한 사실이다. 예전에는 리부팅하거나 커널을 다시 컴파일해야만 변화시킬 수 있었던 영역까지 sysctl 인터페이스를 정의하여 sysctl 호출을 사용하면, 특정 커널의 매개변수를 변화시킬 수 있도록 해준다. /proc 파일 시스템을 사용하는 경우 /proc/sys 라는 디렉토리의 파일 내용에 echo 명령 등으로 원하는 값을 적어 변화시킬 수 있다. 예를 들어 /proc/sys/kernel/file-max 는 시스템이 최대 허용하는 파일 열기 갯수인데 시스템이 과다하게 파일을 사용하여 한계에 다다르면 이 값을 늘려주기만 하면 된다. 설치/부트 디스켓 용도로 커널을 만드는 것이 아니라면 Y를 선택한다.
기타 바이너리에 대한 실행 지원(Kernel support for MISC binaries) 리눅스가 기본적으로 지원하는 실행 바이너리는 ELF 방식이다. a.out, 자바 바이트 코드 또한 지원한다. 자바 바이트 코드를 실행하면 주어진 위치에서 자동으로 자바 가상 머신을 불러다 쓰는 모듈을 더욱 확장하여 일반화 시킨 것이 바로 MISC(기타) 바이너리 지원이다. 이 기능에 Y 로 답변하거나 모듈로 만든 후 binfmt_misc.o 모듈을 로딩시키고 문서 디렉토리의 binfmt_misc.txt 에 적힌 절차대로 /proc 파일 시스템에 등록해 주면 된다. 예를 들어 mp3 파일에 실행 퍼미션을 주고 실행시키면
자동으로 지정한 해석기를 앞에 붙여 실행하게 하고 싶다면 다음처럼
한다.
우리가 쉘 스크립트 맨 앞줄에 #!/usr/bin/perl
처럼 적어 해석기를 명시하는 것과 같은 개념을 확장시킨 것이라고
보면 된다. 참고로 이 기능이 특히 유용한 곳은 알파/리눅스로서
em86 이라는 에뮬레이션 프로그램을 사용하여 인텔/리눅스용 프로그램을
투명하게 실행시키고자 할 때 등록만 해두면 알아서 적절한 해석기를
사용하여 실행하게 되므로 편리하다. 문서파일에 보면 도스 프로그램이나
윈도우즈 프로그램을 각각 DOSEMU와 WINE으로 돌리게 하는 방법이
적혀있다.
병렬 포트 지원 병렬 포트에 프린터, ZIP 드라이브를 연결하여 사용하거나 PLIP 네트웍을 사용하고 싶을 때는 이 기능을 선택해야 한다. 그 밖에도 병렬 포트를 사용하는 장치는 매우 많다. 여러 장치가 같은 병렬 포트를 공유하여 사용하는 것도 가능하다. 예를 들어 페러렐 버전의 ZIP 드라이브와 프린터를 하나의 포트에 연결한 채 같이 사용할 수 있다. PC 스타일 하드웨어 모든 IBM 호환 하드웨어와 일부 알파 머신은
PC 스타일의 병렬 포트를 가지고 있다. 외부 하드웨어 지원 비표준 형식의 병렬 포트 드라이버 모듈을 사용할 때 필요한 옵션이다. 전체적인 성능을 저하시키는 경향이 있기 때문에 일반적으로 N 이다.
플러그 앤 플레이 지원 이제 겨우 플러그 앤 플레이를 지원하려고 시작한
것일까? 플러그 앤 플레이에 관한 한 개발 버전이라 할 지라도 아직
크게 기대할 것이 못된다는 사실을 분명히 해둔다. 윈도우즈 95
처럼 풍부한 수준의 PnP 기능은 이미 구현되어 있는 드라이버를
몹시 많이 고쳐야 하기 때문인지 우리가 기대하는 만큼 들어와 있지
않다. 고작 해야 병렬 포트에 연결된 장치에 대한 자동 인식 정도가
들어있을 뿐인데 어찌 되었든 PnP 에 대한 고려는 하고 있는 것
같다.
병렬 장치 자동 조사 IEEE-1284 규격을 준수하는 병렬 포트 장치를 조사하여 인식할 수 있게 해주는 기능이다. 모듈로 선택하면 parport_ieee1284.o 라는 파일이 생성된다.
플로피, IDE 및 기타 블록 장치 지원 일반적인 PCI IDE 칩셋 지원 IDE 하드디스크를 사용하는 PCI 시스템을 지원하는 옵션이다. 일반적인 PCI 버스 매스터 DMA 지원 대부분의 펜티엄 PCI 시스템은 IDE 하드 디스크에 대하여 버스 마스터(Bus-Master) DMA를 지원한다. 버스 마스터링을 사용하면 CPU의 부담이 약간 덜어지기 때문에 유용하다. DMA 기능을 사용할 때는 부팅 중 하드 드라이브 정보 옆에 DMA라는 표시가 붙는다.
다중 장치(Multiple Device) 지원 다중 장치(MD) 드라이버에 기존의 선형(Linear) 모드와 RAID-0(띠 모드) 이외에도 미러링 기능의 RAID-1, 그리고 RAID-4/5 까지 소프트웨어적으로 지원한다. 고속의 SCSI 디스크와 함께 사용하면 전반적인 입출력 속도가 개선되며 RAID-4/5 경우에는 귀중한 자료가 불의의 사고로 유실되는 것을 최대한 막을 수 있다. 커널 도움말을 보고 RAID에 관련된 프로그램을 가져와야 한다.
병렬포트 지원 병렬 포트를 사용하는 IDE 장치 지원 기능이 공식적으로 들어와 있다. 병렬 포트에 연결하는 IDE 하드디스크, ATAPI 디스크/시디 롬, 테잎 장치가 광범위하게 지원된다. 기능을 선택하면 제품 고유의 프로토콜을 선택할 수 있다.
네트워킹 옵션 네트워킹 옵션 부분은 전문 네트워킹 용어가 많이 나오기 때문에 초보자의 경우에는 이런 용어들도 있다는 수준에서 부담없이 읽어 나가기 바란다. 여기에 나오는 용어를 모른다고 해서 리눅스 네트워킹을 제대로 할 수 없는 것은 아니기 때문이다.
유닉스 도메인 소켓이 모듈로도 가능 유닉스 도메인 소켓이 모듈로도 설정 가능하게 되어 있다. 일반적으로 많은 프로그램들이 지역적인 네트웍 연결을 할 때 필요하므로, 내장(Embedded) 시스템과 같이 최소의 기능이 요구되는 환경이 아니면 Y 라고 해두어야 한다. 만약 모듈로 설정했다면 꼭 alias net-pf-1 unix 라는 문장을 /etc/conf.modules 에 추가하여 커널 데몬이 자동으로 처리할 수 있도록 해주어야 한다.
라우팅 관련 기능의 기능 추가 및 개선 향상된 라우터(advanced router) 옵션은 리눅스 박스를 주로 네트웍 패킷을 받아 전달하고 분배하는 라우터 기능 용도로 사용하는 컴퓨터에서 선택한다. 이 옵션을 선택하면 몇 가지 라우터 관련 옵션들이 제시된다. 여러분의 리눅스 박스를 매스커레이드(Masquerade) 박스로 사용하고 있다면 라우팅 기능을 선택해야 한다. 매스커레이드란 라우팅의 특수 기능이다. 주의할 것은 라우터 기능을 하기 위해서는 시스템 시작 중 다음과 같은 명령을 사용해야 한다는 것이다. 이미 레드햇 5 리눅스에서 IP 관련 설정에서 만나 본 적 있는 명령이다. echo "1" > /proc/sys/net/ipv4/ip_forward 한 때 ip_forward 라는 파일명을 ip_forwarding 으로 바꾸었다가 다시 ip_forward 로 돌아왔다. 잠시 파일명에 대하여 갈팡질팡하여 혼란을 불러일으키기도 했다. 정책적인 라우팅(policy routing)은 라우팅 과정에서 패킷의 목적지 주소뿐 아니라 패킷의 발신 주소와 패킷이 온 네트웍 장치를 고려하여 좀더 똑똑한 라우팅을 가능케 해주는 옵션이다. 일반적으로 라우팅 테이블은 주어진 패킷에 대하여 고정적인 라우팅 결정을 내리게 된다. 하지만 동일 비용 다중경로(equal cost multipath) 기능을 선택하게 되면 특정 패턴의 패킷에 대하여 여러 경로를 동적으로 사용할 수 있게 된다. 라우팅의 결정 요소로 TOS(Type Of Service)를 사용한다는 것은 보통의 경우 간단히 무시되고 있는 패킷의 TOS 정보를 라우팅 결정에서 고려한다는 것이다. TOS 란 패킷이 고속 전송을 위주로 하는 것인지 아니면 안정적인 전송을 우선하는지 등의 부가 정보를 가진 필드를 말한다. 자세하게 라우팅 감시하기(verbose route monitoring) 기능을 켜두면 klogd 에 의해 라우팅 메시지를 검사할 수 있게 된다. 이상한 패킷들이 발견되면 경고 메시지가 출력되므로 네트웍 설정의 실수나 외부의 네트웍 공격을 알아 챌 수 있다. 거대 라우팅 테이블(large routing tables) 기능은 64개 이상의 라우팅 테이블이 필요한 경우 속도를 향상 시키기 위해 선택한다. 일반적으로 거대 라우팅 테이블은 필요치 않다. 빠른 속도로 네트웍 주소 전환하기(fast network address translation) 기능을 사용하면 리눅스 박스를 통과하는 패킷의 발신지/목적지 주소를 재빠르게 수정할 수 있다. 필자의 생각으로 빈번한 주소 변경 작업이 필요한 매스커레이드 리눅스 박스에서 필수적인 기능이라고 본다. 커널 수준에서의 자동 설정 기능(kernel level autocon-figuration)은 네트웍 장치의 IP 주소와 라우팅 테이블을 커널이 알아서 처리하는 것으로서 BOOTP 또는 ARPA 프로토콜을 사용하는 디스크 없는 리눅스 워크스테이션의 네트웍 부팅에서 사용한다. 보통의 독립형 리눅스 박스에서는 필요치 않다.
SCSI 지원 SCSI 어댑터 지원 부분은 일상적인 하드웨어 드라이버 새로 추가하기, 기존의 드라이버 개선하기일 뿐이다. 주로 많이 변화하는 드라이버로는 악명 높은 아답텍 계열의 SCSI 드라이버를 들 수 있다. 이 내용을 기술하기에는 지면이 너무 부족하며 시간도 부족하다.
네트웍 장치 지원 네트웍 장치 지원 역시 끝없는 하드웨어와의 전쟁이라는 연장선상에 놓인다. 새롭게 들어온 주요 장치로는 WAN 드라이버로서 상고마(Sangoma) WANPIPE(tm) 라는 다중 프로토콜 카트 드라이버이다. 이 카드는 X.25, 프레임 릴레이, PPP 등 여러 프로토콜을 지원하는 다목적 카드이다. X.25 망에 연결하기 위해서는 여러 가지 방법이 있는데, CISCO 와 같은 라우터에 X.25 특별 장치를 장착하여 연결하는 경우, 이더넷을 통해 LAPB 드라이버를 사용하거나 일반적인 비동기 시리얼 라인을 통해 X.25 패킷을 받는 방식인 X.25 비동기 드라이버가 사용할 수 있다. 그리고 두 개의 하드웨어에 대하여 무선 LAN 드라이버가 제공되고 있다는 점도 눈여겨볼 만하다. Metricom 무선 장치와 Lucent Wavelan 등의 장치가 지원된다. 애플 플랫폼으로의 리눅스 포팅이 진전되면서 애플토크(Apple Talk) 관련의 드라이버가 많아졌다는 것도 눈에 띈다.
아마추어 무선 통신과 ISDN 이 분야에 대해서는 필자의 경험이 전무하기 때문에 독자들의 경험담을 간절하게 듣고 싶다. 특히 ISDN의 경우에는 대한민국의 어느 지역에서 어느 제조업체의 어느 제품이 리눅스와 잘 맞는지 많은 사람들이 궁금해 할 것이라 생각한다. 동호회 게시판이나 유즈넷 뉴스그룹 또는 리눅스 월드 앞으로 경험담과 기술적인 설명을 적어주기를 기대한다.
파일 시스템 리눅스는 가상 파일 시스템(VFS) 계층이라는 것을 두어 파일 스스템 드라이버를 철저하게 모듈화 시키고 있는 운영체제로서 현존하는 운영체제 중 가장 많은 파일 시스템을 제공한다고 말할 수 있다. 주요 변화를 보자면 우선 이제는 더 이상 현실적으로 사용되지 않는 ext 파일 시스템(ext2 파일 시스템의 전신)이 완전히 제외되어 버렸다. 기대와는 달리 아직 FAT32를 지원하지 않는다. 그렇지만 비공식적으로 안정적인 FAT32 패치가 있다.
마이크로 소프트 졸리엣(Joliet) 확장 기능 마이크로소프트사는 기존의 표준을 간단히 무시하고 새로운 강압적 표준을 만드는데 능한 회사이다. 윈도우즈 95로 오면서 도스의 8.3 자 제한을 넘은 마이크로소프트사는 역시 기본적으로는 8.3 자에 불과한 시디롬 파일 시스템 ISO9660에 졸리엣이라는 특수 확장 기능을 만들어 넣었다. 이미 유닉스와 같이 긴 파일명 문제를 해결하기 위한 락릿지 확장 기능을 그들은 사용하지 않는다. 일단 저지른 일, 리눅스는 졸리엣을 지원한다. 졸리엣에서는 16 비트 유니코드를 사용하기 때문에 자국 언어 지원에서 코드 페이지를 선택하여 컴파일해야 한다.
코다(Coda) 파일 시스템 코다 파일 시스템은 NFS 와 같은 유닉스 네트웍 파일 시스템으로서 많은 면에서 NFS 보다 우월한 진보적 파일 시스템이라는 평가를 받고 있다. 예를 들어 랩탑 컴퓨터와 같은 이동형 컴퓨팅을 고려하여 접속을 끊은 상태에서의 작업을 지원하며, 읽기/ 쓰기 서버 반복 작업, 인증과 암호화, 클라이언트 쪽의 항상적인 캐쉬와 되쓰기 캐쉬등을 지원한다. 코다 파일 시스템을 선택하면 코다 파일 시스템을 사용할 수 있는 클라이언트가 될 수 있다. 코다 파일 시스템 서버는 사용자 영역에서 구현되어 있기 때문에 커널에서 선택하지 않는다. 코다에 비해 NFS 는 매우 엉성하고 여러 가지 문제점들을 가지고 있으나 일단 많이 쓰이고 있다는 사실 하나만으로 대체하기 힘들다는 점을 들지 않을 수 없다.
NFS 서버 지원 NFS 서버로서의 리눅스의 성능을 향상시키기 위해 그 동안 사용자 영역에서 처리했던 NFS를 커널 영역에서 처리하도록 개선하였다. 그 동안 리눅스가 NFS 영역에서 만큼은 다른 유닉스보다 한참 뒤떨어진다는 것이 공식적인 평가였다. 그냥 기존의 사용자 영역 처리 프로그램인 nfsd를 사용하는 경우에는 N이라고 선택한다. 커널 차원의 NFS 서버를 사용하려면 Y 또는 M을 선택한다. 아직 실험적인 수준이지만 일단 사용자 영역 처리 방법보다 훨씬 빠르다는 장점을 갖는다. 새로운 기능의 NFS를 사용하기 위해서는 Olaf Kirch 씨가 관리하는 새 버전의 linux-nfs 패키지를 설치해야 한다.
윈도우즈 NT 파일 시스템인 NTFS 지원 윈도우즈 NT에서 사용하는 NTFS 파일 시스템을 마운트하여 읽을 수 있도록 해주는 기능이다. NTFS 파일 시스템에 쓰기 작업은 아직 실험적인 수준이라고 한다. 많은 사람들의 헌신적인 테스팅이 필요한 영역이다.
기타 파일 시스템 애플 하드웨어에 리눅스가 포팅되어 감에 따라 애플 매킨토시 파일 시스템, 매킨토시 파티션 맵 등이 지원된다. 초기 램 디스크 또는 설치 디스크에서 사용할 수 있는 ROM(읽기 전용) 파일 시스템 드라이버도 들어와 있다.
자국어 지원(Native Language Support) 마이크로소프트 FAT 파일 시스템에 관련된 내용이다. 파일명은 DOS 코드 페이지라는 이름의 자국어 문자 셋으로 처리되어 있다. 따라서 파일명을 제대로 읽고 쓸 수 있기 위해서는 적절한 코드 페이지 모듈을 선택해야 한다. 한국어의 코드 페이지는 949 이지만 아직 커널에 들어있지 않은 상태이다. 제시되고 있는 선택 사항들은 유니코드 테이블로부터 자동으로 생성된 소스라고 한다. 관심있는 독자들은 코드 페이지 949를 넣어 커널 개발자에게 보내는 것이 어떨까?
문자 장치 적지 않은 문자 장치 드라이버가 개선되고 추가되었다.
PC110 디지타이져 패드 IBM PC110 팜탑 컴퓨터에 장착되어 있는 디지타이져 패드를 사용할 수 있게 해주는 드라이버이다. 디지타이져를 PS/2 마이스 에뮬레이션할 수도 있고 실제 디지타이져 모드로 사용할 수도 있다.
비디오 관련 기능(Video For Linux) 리눅스에도 이제 점차적으로 윈도우즈 95 에서나 만끽할 수 있었던 비디오 관련 기능들이 추가 되기 시작했다. 일부 오디오/비디오 캡춰 보드와 오버레이 장치를 지원한다. BT848 칩을 사용하는 프레임 잡기/오버레이 장치 드라이버, 커넥틱스 사에서 나오는 흑백 퀵캠(QuickCam), 컬러 퀵캠 카메라 드라이버, 미디어비젼 프로 무비 스튜디어 비디오 장치 드라이버가 제공되며, 이 분야에 대하여 앨런 콕스씨가 열심히 작업 중이므로 많은 성과들이 계속적으로 추가될 것이다. 실제로 활용하기 위해서는 몇 가지 응용 프로그램을 구해야 한다.
NVRAM(Non-Volatile RAM) 지원 PC 의 CMOS RAM 또는 Atari 의 겨우 NVRAM 이라고 부르는 메모리 공간에 50바이트의 비휘발성 공간이 있다. 이 공간은 전원이 단절되어도 보존되기 때문에 여러 용도로 사용할 수 있다. 여러분이 직접 사용할 기회는 별로 없을 것이다. 모듈로 컴파일하면 nvram.o 라는 파일이 생성된다. 우선은 /dev/nvram 이라는 장치를 만들어야 한다. 메이져 번호는 10, 마이너 번호 144 의 문자 장치이므로 다음과 같이 만든다. # mknod /dev/nvram c 10 144 그 다음 모듈을 적재하자. # modprobe nvram 문자 장치를 사용하는 방법은 매우 간단하다. 명령 행에서 간단히 처리하려면 어떤 자료를 쓰고 싶을 때 echo 등의 명령을 사용하고 읽고 싶을 때는 cat을 사용하면 된다. 필자는 우선 NVRAM 상에 쓰레기(garbage) 값을 지우기 위해 다음처럼 하였다. # dd if = /dev/zero of = /dev/nvram bs = 1 count = 50 읽고 쓰기 테스트를 해보았다. # echo "I Love Moon" > /dev/nvram 매우 간단하며 직관적이다. 여러분이 프로그래머로서 NVRAM을 어떤 용도로 사용하길 원한다면 얼마든지 사용할 수 있다. 하지만 필자의 시스템에서는 리부팅 후 NVRAM 에 저장한 값이 다시 쓰레기 값으로 변하는 것을 목격하였다. 전원이 나가도 값을 보존한다는 설명과 필자의 실제 상황과는 약간 차이가 있었는데 여러분의 경험은 어떠한지 알고 싶다.
PC 조이스틱 지원 PC 호환 아날로그/디지탈 조이스틱을 사용할 수 있다. 메이져 번호 15, 마이너 번호 0, 1 의 장치를 만들면 X, Y 좌표와 버튼 상태를 읽어들일 수 있다. 리눅스 게임의 시대를 여는 것일까?
라디오 장치 지원 PC에서 라디오를 청취할 수 있도록 해주는 카드를 지원하는데, 현재 지원되는 모델은 AIMSlab RadioTrack 뿐이다. 필자는 국내에서 판매되고 있는 라디오 장치에 대한 지식이 없으므로 이 부분도 여러분의 도움을 원한다.
사운드 아직 PCI 사운드 카드에 대한 지원이 많지는 않지만 꾸준히 새로운 사운드 카드 기능이 들어가고 있다. 개발 버전 2.1에서 획기적으로 달라진 것은 사운드 기능의 모듈화이다. 그 동안 리눅스 커널의 다른 부분과 달리 사운드 기능은 모듈화가 엉성하게 이뤄져 있었기 때문에 특정 사운드 카드를 꼭 컴파일할 때, 결정해야 했다. 하지만 앨런 콕스씨 등의 노력으로 사운드 기능도 철저한 모듈화의 길을 걷게 되었고 레드햇 5 리눅스를 설치해 본 사람들은 이미 사운드 모듈 기능을 맛보았을 것이다. 사운드 관련의 각종 매개 변수는 사운드 모듈을 올릴 때 지정할 수 있다. 대체로 사운드 블래스터 호환은 리눅스에서 아무 문제없이 사용할 수 있다. 아직까지 윈도우즈 95 만큼의 사운드 드라이버 지원은 기대하기 힘들다.
커널 해킹 긴급 요술키 지원(Magic SysRq key) 리눅스를 비롯한 커널 개발자들은 커널을 개발하면서 얼마나 자주 시스템을 날려 먹었을까? 궁금하지 않은가? 커널 레벨의 프로그래밍은 보호해 줄 어느 누구도 없기 때문에 약간의 실수만 있어도 시스템은 그냥 서 버리고 만다. 도저히 아무 것도 할 수 없는 치명적인 상태가 아닌 경우 긴급하게 시스템을 안전한 상태로 리부팅시키는 기능이 들어 있다. 바로 긴급 요술 키이다. 콘솔 상태에서 <Alt>+<SysRq>+<N> 키를 동시에 눌러보자. 실수로 누르는 일이 없도록 키 배열을 서로 멀리 해 놓았기 때문에 농구 선수의 손이 아니라면 두 손을 이용하여 눌러야 한다. SysRq : unRaw saK Boot Off Sync Unmount
showPc showTasks showMem 주로 X 서버 또는 SVGA 프로그램이 다운되어 콘솔을 엉망으로 만들었을 때는 ALT-SysRQ-r키를 눌러 키보드 Raw 모드를 꺼서 커널이 모든 키를 가로채도록 만들 수 있다. 이때는 Ctrl+Alt+Del 키 등이 제대로 작동할 것이다. k 키를 같이 누르면 현재 가상 콘솔에서 실행 중인 모든 프로그램을 종료시킨다. b를 누르면 하드디스크 언마운트 과정 또는 메모리 캐쉬 내용을 하드로 전달하는 과정 없이 즉시 리부팅하도록 한다. o 키는 APM 기능을 이용하여 시스템을 셧다운시키는 키이다. u 키는 모든 파일 시스템을 읽기 전용 모드로 다시 마운트시키는 명령을 내린다. e,i 키는 init 프로세스를 제외한 모든 프로세스에게 각각 TERM, KILL 시그널을 보낸다. l 키는 무조건 모든 프로세스를 죽여 버린다. 긴급 상황에서 쓸수 있는 좋은 기능이므로 잘 알아두기 바란다.
강철 심장을 가진 사람만 초대합니다. 커널 2.1.102 버전이 나와서 즉시 컴파일 해보니 몇 가지 문제를 만나게 되었다. 일단 ncurses를 사용하는 커널 설정방식인 make menuconfig 가 작동하지 않았다. 이틀 정도 지나 뉴스 그룹을 뒤져보니 역시 같은 문제를 겪는 사람들이 있었고 패치 파일이 나와 있는 상태였다. 또한 동생의 컴퓨터를 하나의 IP 에 공유 시켜주고 있는 IP 매스커레이딩 도구인 ipfwadm 이 제대로 작동하지 않았다. 필자는 이 글을 작성하는 지금 2.1.101을 사용하고 있다. 2.1.102 버전에는 방화벽 기능에 대하여 새로운 IP 방화벽체인 기능이 들어가 있다. http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html을 방문하면 ipfwadm과 같은 기능을 더욱 개선된 형태로 해주는 프로그램을 얻을 수 있다. 리누스가 당분간 새로운 기능의 패치를 보내면 읽지 않고 무시해 버릴 것이라는 엄포를 놓고 코드 종결 작업을 시작하였으니 한두 달이면 새로운 안정 버전 2.2를 기대할 수 있을 것이다. 조급한 마음에 2.2를 기다리기 힘든 사람은 당장에 개발 버전 2.1최신 버전을 받아서 시험해보라. 혹시나 생길지 모르는 불상사에 대비하는 것을 잊지 말기 바란다. |