제 3 회 리눅스 공동체 세미나 g 세션
커널! 알아보고, 만저보고, 컴파일해보자!
고려대학교 리눅스동아리 kuls
심상현 <artsilly@kuls.korea.ac.kr>
커널의 역사와 커널의 개발 과정, 커널에 얽힌 여러 비사들, 커널 메인테이너, 커널을 구할 수 있는 곳, 새로운 커널 컴파일, 커널 컴파일에 따르는 여러 옵션들, 커널 모듈등에 대해 다룹니다. 누구나 쉽게 커널을 컴파일 할 수 있도록 여러분을 초대합니다.
|
|
제 3 회 리눅스 공동체 세미나 g 세션 |
|
|
커널! 알아보고, 만저보고, 컴파일해보자! |
||
|
|
||
|
|
|
|
|
고려대학교 리눅스동아리 kuls 심상현 <artsilly@kuls.korea.ac.kr> |
||
|
커널의 역사와 커널의 개발 과정, 커널에 얽힌 여러 비사들, 커널 메인테이너, 커널을 구할 수 있는 곳, 새로운 커널 컴파일, 커널 컴파일에 따르는 여러 옵션들, 커널 모듈등에 대해 다룹니다. 누구나 쉽게 커널을 컴파일 할 수 있도록 여러분을 초대합니다. |
||
커널! 알아보고, 만저보고, 컴파일해보자! 197
------------------------------------------------------------------------------------------------
1. 커널이란 무엇인가? 컴파일이란 무엇인가?
1.1 커널
운영체제만을 연구하는 학문에서는 커널을 여러가지면에서 살펴보고 다양하게 정의 내리고 있다. 그러나 그런 내용들은 너무나 전문적이고 또한 내용이 너무 이론적이다. 여기서는 좀더 쉬운 접근 방법으로 커널에 대한 이야기를 하도록 하겠다.
커널은 운영체제를 움직이는 핵심이다. 자동차에 여러 부속들이 있어도 우리가 자동차라고 부르는 것은 엔진과 조향장치등 자동차를 생각함에 있어서 빼어 놓을 수 없는 것들이 있을 것이다. 이것은 자동차의 커널이 될 것이다. 전체 운영체제에서 커널만을 따로 떼어내어 구분 짓는 것은 약간의 무리가 따르는 일이지만 꼭 구분하자면 그렇다는 것이다. 사실 리눅스를 사용하면서 ls라는 유틸리티가 없다면 무척이나 답답하겠지만 어떤 파일이 있는지 알지 못하면서도 리눅스는 운영될 것이다. 자동차에서도 헤드라이트가 없다면 답답하겠지만 자동차는 달려갈 수 있는 것과 마찬가지 이다.
어떤 운영체제는 커널과 사용자가 사용하는 쉘등의 겉모습이 밀접하게 연결되어 있어 따로 분리해 내기가 어렵기도 하고 또 다른 운영체제는 커널을 어느정도는 따로 떼어내 볼 수 있다. 리눅스의 경우는 후자 쪽에 가깝다고 할 수 있겠다.
우리가 일반적으로 리눅스라고 부른는 시스템은 리눅스라 불리우는 커널에 gnu의 여러 시스템 유틸리티들을 연결한 gnu/linux 시스템이다. 실제로 이 gnu/linux 시스템은 gnu와 gnu의 커널인 hurd를 연결한 hurd 시스템으로 사용 가능하다. 결국 시스템과 커널이 따로 떨어져 나올 수 있는 것이다.
1.2 커널은 무슨 일을 하는가?
전형적인 유닉스의 커널과 비슷한 역할을 하는 리눅스의 커널은 기본적으로 사용자가 작동시키는 응용프로그램과 하드웨어간의 조정자 역할을 맡는다. 동시에 수행되는 여러 응용프로그램들(엄밀히 말하자면 프로세스들과 쓰레드들이다.)을 위해 메모리관리를 해 주며 컴퓨터 자원을 배분하는 역할을 해 준다.
1.3 컴파일이란 무엇인가?
컴파일이란 컴파일러를 이용하여 프로그램 소스로부터 수행가능한 바이너리 코드를 만드는 과정을 말한다. 리눅스 소스는 거의 대부분 c 언어로 작성되었으며 약간의 어셈블리 코딩을 가지고 있다.
1.4 그렇다면 리눅스 커널 컴파일이란 무엇인가?
리눅스는 커널의 소스를 완전 공개한 운영체제여서 커널의 소스를 사용자가 직접 컴파일 할 수 있다. 그렇다면 제작사에서 만들어내서 제공되는 커널과 사용자가 커널을 직접 컴파일 할 수 있다는 것의 차이는 어떤 것이있을까? 커널 소스가 단 한가지 방법으로만 컴파일이 된다면 제작사에서 아예 컴파일을 해서 주는 것이 좋을 것이다. 그러나 사용자에게 커널 컴파일을 맡겼다는 것은 커널을 컴파일하는데 여러가지 옵션을 제공한다는 것이다. 우리는 이 여러 옵션을 잘 조정해서 커널을 우리 입맛에 딱 맞게 만들 수 있는 것이다. 다시 자동차 이야기로 돌아가보자. 우리가 차를 개조할 수 있다고 생각해 보자. 물론 씨디 플레이어등을 새로 설치하는 것은 자동차의 커널을 개조하는 것이 아니다. 씨디 플레이어등은 유틸리티일 뿐이다. 헛갈리지 말자. 자. 자동차의 커널 수준이라면 엔진을 개조하는 것이다. 기름값이 비싸지니까 엔진을 800cc 경차엔진으로 바꾸자. 그런것이 과연 가능한가? 물론 실제에서는 불가능할 것이다. 그러나 상상을 해 보자. 기름값이 비싸지면 경차엔진으로 바꾸고 힘이 딸리면 3000cc 대형 엔진으로 바꾸고, 별 필요는 없지만 괜히 멋으로 4500cc v6엔진으로도 바꾸어보고 마음대로 바꿀 수 있다면 사용자들의 입맛에 딱 맞출 수 있을 것이다. 리눅스 커널은 이와 같이 자신의 요구와 편의에 따라 쉽게 커널을 바꿀 수 있다.
또한 상용 운영체제에서 제공하는 커널은 여러 사용자들의 요구를 두루두루 맞추어 줘야 하기 때문에 덩치가 커질 수 있지만 리눅스의 커널은 자신의 시스템에 필요한 것만을 사용하기 때문에 좀 더 작고 가볍게 구성할 수 있다. 물론 이런 것들은 시스템의 속도를 빠르게 하는 또 하나의 장점이 될 수 있다. 혹 여러 기능이 많은 커널이 더 좋지 않느냐는 의문을 가질 지도 모르겠다. 다음과 같은 경우를 생각해 보자. 현재 리눅스를 쓰고 있고 프린터가 없다면 아마 프린터 포트는 쓸일이 없을 것이다. 그럼 프린터를 구입할 때까지는 프린터 포트 지원을 하지 않음으로 좀 더 가벼운 커널을 사용하고 나중에 프린터가 생기면 프린터 포트를 지원하게 컴파일 하면 되는 것이다. 프린터가 없을 때도 내부적으로 프린터를 지원하게 해 놓으며 컴퓨터의 자원을 낭비할 필요가 없다는 것이다.
2. 리눅스 커널 업그레이드?
사실 리눅스의 커널의 업데이트가 늦다면 커널 컴파일은 처음 시스템을 설치할 때나 새로운 하드웨어를 추가할 때 혹은 이전에 사용하지 않던 기능을 사용하고자 할 때로 한정될 것이다. 그러나 리눅스 커널은 지금 이 순간에도 계속하여 새롭게 바뀌어 가고 있다. 그 이유는 아래와 같다.
새로운 하드웨어의 지원
시스템 관리 능력의 개선
속도 개선
버그 수정
리눅스 커널은 무척이나 빠른 속도로 업데이트 되고 있기 때문에 매번 커널을 업그레이드 한다면 매번 시간과 노력이 들 것이다. 게다가 비록 안정버전이라 하여도 어떤 버그가 있을지 모르기 때문에 공식적으로 서비스를 하는 리눅스 시스템일 경우는 커널 업데이트를 삼가며 pc 통신이나 유즈넷등의 소식을 참고하여 약간 오래되었더라도 안정적인 커널을 사용하는 것이 좋다. 그러나 일반 클라이언트로 사용되는 개인용 리눅스 박스의 경우는 주기적으로 새로운 커널을 사용해 보는 것도 권장할 만하다. 하긴 말려도 새로운 커널이 나올 때 마다 매번 커널 컴파일을 하는 커널 컴파일 광이 있는가 하면 커널 컴파일이 무엇인지 조차 모르고 있는 사람도 많다. 자신의 생각에 따라 다르겠지만 생각해 보라. 자신의 시스템에 딱 맞는 커널을 항상 새롭게 유지한다는 기쁨을.
3. 커널 구하는 방법
일반적으로 대부분의 배포본은 안정적인 커널 소스와 아주 일반적인 방법으로 컴파일된(다른 상용 운영체제의 커널처럼 거의 모든 기능을 제공하는 커널) 커널이 제공된다. 만일 그런 커널을 제공하지 않는다면 리눅스를 설치한 후 바로 사용이 불가능할 것이다. 새로운 커널 소스는 다음 사이트에서 구할 수 있다.
ftp://ftp.kernel.org
위 커널사이트의 미러사이트는 다음과 같은 형식의 url을 갖는다.
<ftp://ftp.국가명.kernel.org>
즉 우리나라는 ftp://ftp.kr.kernel.org을 대표 미러사이트로 갖는다. 물론 위 사이트들 외에 pc 통신망이나 그밖의 공개 ftp에서도 쉽게 커널 소스를 구할 수 있다. 최근의 커널 소스는 용량이 압축해서 약 13mb정도이다.
4. 커널 관리자, 그밖에 커널에 대한 이야기
최초의 리눅스 커널이 리누스로부터 만들어진 이후 리눅스 커널의 정식 배포는 리누스만 가능하다. 즉 누구든지 커널 소스를 변경하여 자신의 입맛대로 사용 가능하지만(옵션 변경뿐 아니라 프로그램 자체를 변경가능하다.) 그것일 뿐이다. 리누스를 제외한 어느 누구도 리눅스 커널 소스를 변경했다고 커널의 버전을 올려 배포할 수는 없다. 전세게 리눅서들에게 온 버그레포트를 토대로 버그를 잡고 여러 사람의 도움을 받아 새로운 기능을 추가하고 리누스의 맘에 들면 커널의 버전이 올라가는 것이다.
4.1 커널 버전 규칙
리눅스 쪽에서는 버전에 대해 무척이나 인색하다. 커널 역시 0.1.x 에서부터 시작되었으며 1991 년에 이르러서야 1.0.0에 이르렀다. 맨 앞의 숫자는 엄청난 아주 엄청난 변혁에 이르렀을때야 올라간다. 일반적으로는 두번째 자리의 숫자가 올라가는 것만으로도 많은 변화가 있다고들 생각한다.
두번째 자리 숫자는 특별한 의미를 가지고 있다. 홀수는 개발버전, 짝수는 안정버전으로 불리운다. 즉 2.0.x는 업무에 써도 충분할 정도로 안정성을 갖춘 커널을 의미하고 2.1.x는 여러가지 아직 불완전한 코드나 실험적인 성격이 짙은 부분을 포함한다. 개발버전에서 테스트가 끝난 코드는 안정버전으로 다시 들어가게 된다.
마지막 자리의 숫자는 버그를 잡고 몇몇 오류를 수정한 후 하나씩 올리게 된다. 또한 개발버전에 있는 코드가 안정버전으로 들어오는 경우에도 마지막 자리 숫자가 올라가게 된다.
지금까지는 한 안정버전과 그 다음 안정버전을 준비하는 개발버전이 약 1년에서 1년 반정도 유지되고 그 다음 안정버전이 나오곤 했다. 그러나 최근에 들어서는 개발 속도가 점차 빨라지는 경향이다. 최신의 안정버전은 2.2.x대이다.
4.2 또 한명의 커널 관리자
2.1.x대의 커널이 한참 개발되고 있던 중 리누스에게 몰리는 과중한 커널에 대한 업무가 또 한명의 해커에게로 분산되었다. 충분히 전세계의 리눅서와 리누스에게 인정을 받으며 그는 리누스가 정한 커널 버전에 자신의 패치 버전을 달 수 있는 권한(?)까지도 갖게 되었다. 앨런 콕스가 바로 그사람이다. 그의 홈페이지에는 리눅스 박스와 커널에 대한 일기형식의 글을 볼 수 있으며 매일매일 새로운 커널을 테스트하고 전세계로부터 날아드는 패치들을 정리해 리누스가 새로운 커널 버전을 내어 놓기 전에 ac 라는 꼬리를 달아 그의 패치를 내어 놓는다. 즉 2.2.4 버전 커널에 대한 앨런콕스의 패치는 2.2.4-ac1 이런식으로 이름이 붙는다. 최근의 많은 사람들은 앨런콕스의 신속함과 정확함에 점차 그의 패치를 좀 더 신뢰하는 경향도 보이고 있다. 리눅스를 쓰면서 이런 위치에 오른다는 것은 그런 권위나 위치를 자랑해서가 아니라 정말 무한한 영광처럼 느껴진다. 열심히 해킹하길 바란다. 참고로 엄청난 커널 컴파일 광은 이런 작은 패치까지도 틈틈히 패치하여 커널 컴파일을 하는 열정을 보이기도 한다.
5. 커널 컴파일을 위한 최종점검
지금까지 커널에 대한 몇몇 이야기와 커널을 받고 압축을 풀어 컴파일 하기 위한 예비 과정을 수행했다. 마지막으로 자신의 리눅스 시스템이 커널을 컴파일 하기 위한 준비가 되어 있는지 확인해 보도록 하자.
5.1 필요한 프로그램들
당연한 이야기겠지만 위의 과정까지를 잘 수행해 왔다는 것은 지금 리눅스가 깔려있는 컴퓨터가 있다는 것이고 tar나 gzip등 일반적인 유틸리티들이 있다는 것을 의미한다. 일반적인 인텔호환머신에서 리눅스 커널을 컴파일하기 위해서는 기본적으로 gnu c인 gcc와 c 라이브러리인 libc, make 유틸리티, gnu 어셈블러(as86)등이 필요하다. 그러나 커널을 컴파일 한 후 그 커널을 운용하기 위해서는 몇몇 유틸리티나 라이브러리등도 업데이트 되어야 한다. 일반적으로 커널 압축을 푼 /usr/src/linux/documentation/changes 파일에 보면 업데이트가 필요한 몇몇 프로그램들에 대해 나와있다. 많은 경우에 커널을 업데이트 하면서 이런 업데이트가 요구되는 프로그램들을 업데이트 하지 않을 경우 시스템에 오류를 초래할 수 있다.
5.2 디스크 공간
2.2.x의 최신 커널 소스는 압축을 풀고 나면 56mb에 달하는 용량을 가진다. 배포되는 압축된 커널 소스가 13mb 정도 되고 커널을 컴파일 하고 나면 몇몇 중간 파일(obj 파일)이 생성되어 약 10mb 정도가 추가된다. 결국 커널을 컴파일하기 위해서는 약 80mb이상의 여유공간이 필요하다. 리눅스 커널의 크기는 점차 커지고 있는 추세이다. 실제 2.0.x대의 커널은 압축을 풀어 놓은 크기약 30mb정도 였다.
5.3 자신의 시스템에 대한 정보 입수
커널 컴파일을 위해 설정하는 동안 리눅스 박스는 귀찮을 정도로 많은 내용을 물어본다. 자신의 시스템에 대해 정확히 알고 있지 못한다면 최적화된 커널을 컴파일 하기는 커녕 아예 돌아가지 않는 커널을 만들어버리고 말 공산이 크다. 자신의 시스템에 대해서 충분히 알아두도록 하자. 특히 비디오 카드와 모뎀을 제외한 시스템에 달려있는 여러 카드들에 대한 정보는 특히나 중요하다. 잘 모르겠으면 시스템 메뉴얼을 옆에 가져다 두고, 다른 os를 쓰고 있었다면 시스템 정보를 보거나 해서 자세한 내역을 적어두도록 하자.
6. 커널 구동의 전반적인 이해
6.1 컴파일한 커널이 어떻게 운영체제로 동작 가능한가? - 인텔머신
리눅스에서는 구식의 a.out 형식의 바이너리와 대부분이 사용하고 있는 elf 바이너리 형식으로 커널을 만들 수 있다. 바이너리 형식이라는 것은 쉽게 말해 ls나 cp등 우리가 실행할 수 있는 프로그램이라는 말이다. 그러나 리눅스 커널은 이런 방법으로 실행되지 않으며 이런 방법으로 실행해서도 그 목적(커널로서의 목적)을 이루지 못한다. 시스템 부팅과 동시에 커널은 실행되어야 한다. 대부분의 다른 운영체제에서도 커널의 실행과정은 그 운영체제를 사용하는 시스템 하드웨어와 밀접한 관계를 맺고 있다. 하여간 리눅스에서는 그런 역할을 lilo(linux loader)에서 맡고있다. 본 책에서도 리눅스라는 단어를 linux/gnu 시스템을 가리키는 대표적인 말로 말해버리고 있지만 위에 언급한 것 처럼 linux란 커널을 가리키는 것이므로 lilo는 그 단어만으로도 커널을 실행시키는 프로그램이라는 것을 알 수 있다.
사실 커널-리눅스-은 lilo로 실행되지는 않는다. 커널 실행과정은 전적으로 하드웨어의 롬바이오스에 달려있다. lilo는 하드웨어의 롬바이오스가 커널을 알아볼 수 있도록 적절한 위치에 배치시켜 주는 작업을 한다. 지금까지 알아본 것과 같이 커널을 컴파일 하면 lilo를 이용하여 적절한 위치에 커널을 배치하는 것이 필요하다 하겠다. 처음 컴파일을 하고 나서는 무척이나 쉽게 lilo과정을 잊곤 하는데 여기에 대한 주의를 환기시켜야 할 필요가 있다. lilo역시 다양한 옵션과 설정을 필요로 함으로 lilo에 대해서는 추후 자세히 설명하도록 하겠다.
리눅스 커널을 실행시키는 방법이 lilo만 있는 것은 아니다. 도스상에서 리눅스 커널을 실행시켜 주는 loadlin.exe(load linux)라는 프로그램도 있다. loadlin.exe은 리눅스 커널을 실행 시켜준다. loadlin.exe에 대해서도 추후 다루도록 하자.
6.2 컴파일한 커널이 어떻게 운영체제로 동작 가능한가? - 알파머신
위에 말한 것처럼 커널이 수행되는 것은 하드웨어와 밀접한 관계가 있다. 알파머신은 인텔머신과 하드웨어 자체가 다르기 때문에 lilo를 가져다 쓸 수 없다. 전형적으로 알파에서는 milo라 불리우는 부트로더를 이용해 왔으며 최신의 시스템에서는 알파 바이오스의 일부인 srm console이라 불리우는 콘솔에서 aboot를 이용하여 부팅 가능하다. 알파시스템에 대해서는 추후 이야기 하도록 하겠다.
7. 커널 모듈에 대한 소개
버전 숫자 올리기에 깐깐한 리눅스 사용자들이 - 특히 리누스가 - 1.3대의 커널에서 2.0대의 커널로 엄청난 버전 업이 된 가장 큰 변화는 모듈에 있다. 모듈이란 커널에 포함되어야 할 기능들 중 일부를 그 기능이 필요할 때만 메모리에 올리고 그 기능이 더 이상 필요 없을 때는 메모리에서 내려주는 커널의 일부를 말한다. 위에서 예를 들었던 프린터를 보자. 사실 프린터를 구입하고 리눅스 커널에서 프린터 포트를 지원하도록 하게 끔 하지만 어디 그 프린터를 하루종일 사용하는가? 프린터를 사용하는 시간은 매일 개인이냐 회사냐에 다르겠지만 개인의 경우에는 특별히 20분에서 30분을 넘지 않을 것이다.(평균적으로 그렇다는 이야기다. 개중에는 하루에 몇백장씩 뽑으며 종이를 낭비하는 사람도 많다. --;) 그러나 커널의 프린터 포트를 지원하는 부분은 항상 메모리에 있으며 프린터를 하나 안하나 지켜보고 있는 것이다. 아무 할 일도 없는데도 말이다. 만일 이런 프린터 포트를 지원하는 부분을 잠시 떼어내 하드 디스크에 보관해 두었다가 필요할 때만 메모리에 올린다면 좀 더 자원을 유용하게 쓸 수 있을 것이다. 여기서는 모듈로 사용할 때의 장점과 몇몇 문제점 그리고 모듈을 사용하는 방법들에 대해 이야기 하도록 하겠다.
7.1 모듈로 사용했을 때의 장점
필요로 할 때만 메모리에 올리므로 시스템 자원을 아낀다.
이것은 위에 설명한 내용이다. 필요할 때만 메모리에 올리므로 메모리를 비롯한 시스템 자원을 아낄 수 있다.
같은 하드웨어 사용하는 두가지 장비를 번갈아 사용가능하다.
이 이야기는 모듈이야기가 나오면 꼭 나오는 예제중 하나이다. zip드라이브로 대표되는 패러렐 포트에 연결해서 쓰는 이동 가능한 대용량 저장 장치의 경우 프린터와 동시에 물리적으로 연결되어 있다. ms윈도우즈의 경우 전용 드라이버를 이용하여 프린터와 zip 드라이브를 연결해서 쓰지만 리눅스 커널의 경우 프린터 포트에 프린터를 사용하도록 설정하거나 이동 가능한 대용량 저장 장치를 지원하도록 설정할 수 밖에 없다. 커널에서 한번에 한가지 밖에 지원을 하지 못한다. 이 경우 모듈이라는 기능이 없다면 그 개개의 장비에 대한 여러가지 커널을 만들어 놓고 매번 커널을 바꾸어 부팅해 주어야 할 것이다. 누가 이렇게 쓰고 싶겠는가?
이 두가지를 모듈로 이용할 경우 각 장비가 필요할 때 마다 필요한 모듈을 올려주었다 내려주었다 하면 될 것이다. 만일 이런 일이 자동(?)으로 이루어진다면 더 편할 것이다.
사용의 편이성
커널 모듈은 커널 설정을 쉽게 해 준다. 몇몇 하드웨어의 경우 커널에 그 하드웨어가 사용하는 여러 정보를 넣어주어야 한다. 그런데, 메뉴얼도 없고 아무런 정보가 없는 하드웨어라면 어떻게 할 것인가? 혹은 기존의 하드웨어 정보를 수정했다면 어떻게 할 것인가? 처음 경우는 될때까지 컴파일 해 보아야 할 것이다. 두번째도 바뀐 하드웨어 정보를 이용하여 다시 컴파일을 해야 한다. 불합리적이지 않은가? 모듈로 지원되는 커널을 이용하면 매번 옵션을 바꾸어가며 커널을 올릴 수 있다. 새로 컴파일 할 필요 없이 메모리에 하드웨어의 정보를 바꾸어 모듈을 올려주면 된다.
다양한 하드웨어의 사용 가능
실제 리눅스가 메이저 운영체제로 들어오기 전까지는 많은 하드웨어 제작 업체에서 회사의 기밀로 분류되어 있는 여러 정보들을 리눅스 하드웨어 드라이버 제작자들에 공개하는 것을 무척이나 꺼렸다. 아직도 몇몇 업체에서는 하드웨어 정보를 공개하지 않는다.(그렇다면 리눅스 하드웨어 드라이버들은 어떻게 만들어졌는지 궁금하지 않는가? 꽤 많은 부분이 reverse engineering이라 불리우는 해킹기법들 - 윈도우즈 드라이버의 역어셈블, 디버그, 실제 하드웨어 분석등 - 과 몇몇 오픈 소스등을 이용해서 제작되었다. 신기하지 않은가?) 그러나 모듈을 지원하는 리눅스 커널의 경우 많은 하드웨어 제작사들이 자사의 소스를 공개하지 않고 바이너리로 제작된 모듈을 이용하여 드라이버를 배포함으로 다양한 하드웨어를 사용할 수 있는 가능성을 열어주었다고 하겠다. 물론 이런 식으로 바이너리만을 달랑 배포하는 것이 리눅스의 열린 정신에는 맞지 않는다 할 수도 있겠지만 그런 판단은 좀 더 후세에게 맡기는 것도 나쁘지 않을 듯 싶다.
7.2 모듈 사용의 단점
복잡하다
여러 내용들을 모듈화 해 놓을 경우 매번 필요한 모듈을 메모리에 올린다는 것은 매우 귀찮은 일이 될 것이다. 게다가 모듈에 대해서 잘 모르는 사용자는 무척 난감하고 여러 모듈에 대해 설정을 해야 하는 자체에 대해서 당황해 할른지 모른다.
커널 컴파일 시 혼란을 가져온다.
몇몇 모듈 가능한 옵션들은 동시에 모듈화 하던지 동시에 모듈화 하지 않던지 해야 되는 경우가 있다. 아직까지는 커널 컴파일시 설정에 그런 내용들을 자세히 설명해 주거나 몇몇 옵션들이 서로 관계되어 있다는 그런 지시자가 없어서 커널 컴파일시에 무조건 많은 내용을 모듈화 하는 것에도 문제가 있다.
커널의 의존성 문제
위에 말한 것처럼 하드웨어 제작사에서 바이너리로 된 커널 모듈을 지원해서 썩 괜찮은(제작사에서 만들었으니까) 성능을 보인다고 할 때, 누가 그 하드웨어에 대한 오픈 소스는 만들 것인가? 또한 하드웨어 업체에서 이 모듈은 커널 x.y.z 버전에 대해서만 지원하니까 이 버전만 써라라고 한다면 리눅서들이 과연 자유속에서 커널 업그레이드를 하거나 할 수 있을까? 하드웨어 하나를 지원하기 위해 커널 업그레이드를 하지 못하는 상황이 생길 수 있다. 결국엔 새로운 기능이나 버그 패치된 기능을 사용할 수없게 되는 의존성이 생기게 된다. 여하간에 리눅스가 인기를 끌며 리눅스와 돈에 대한 이야기는 항상 문제가 된다.
몇몇 단점이 있을 수는 있지만 모듈이라는 것은 단점보다는 장점이 많다. 그렇게 생각하지 않는가?
8. 모듈의 분류
위에 까지 읽어오면서 눈치가 빠른 독자는 짐작했을지 모르지만 모듈은 대부분 하드웨어에 대한 모듈이 많다. 물론 그밖에도 여러가지 순간순간 필요로하는 기능들은 모듈화 된 것이 많다. 최근에는 많은 기능들이 모듈화 하고 있다. 위의 장점들을 생각해 보면 당연히 그러리라 본다.
리눅스 커널의 모듈은 사실 알아서 잘 분류되어 있다. 커널 모듈은 /lib/modules 밑에 위치한다. 처음 리눅스를 설치했다면 이 디렉토리 밑에 단 하나의 디렉토리가 있을 것이다. 멀티 부팅을 위해 남겨 두었거나 새로운 커널을 컴파일하고 귀찮아서 구 버전의 모듈을 지우지 않았다면 여러 디렉토리가 있을 것이다. 이 디렉토리 이름은 각 커널의 버전에서 사용하는 모듈을 모아놓은 것이다. 저자는 귀찮아서 아래와 같이 엄청난 디렉토리들이 쌓여있다.
[linux /lib/modules]$ ls -al
total 11
1 drwxr-xr-x 10 root root 1024 jan 27 19:04 ./
2 drwxr-xr-x 4 root root 2048 dec 18 23:59 ../
1 drwxr-xr-x 7 root root 1024 feb 5 21:39 2.2.0/
1 drwxr-xr-x 7 root root 1024 jan 1 15:41 2.2.0-pre1/
1 drwxr-xr-x 7 root root 1024 jan 2 12:14 2.2.0-pre2/
1 drwxr-xr-x 7 root root 1024 jan 5 12:55 2.2.0-pre4/
1 drwxr-xr-x 7 root root 1024 jan 12 03:02 2.2.0-pre6/
1 drwxr-xr-x 5 root root 1024 dec 30 02:28 2.2.0-pre1.1/
1 drwxr-xr-x 7 root root 1024 dec 30 04:51 2.0.36/
1 drwxr-xr-x 10 root root 1024 dec 18 23:55 2.0.36-1kr/
현재 사용중인 커널은 대부분의 시스템에서 콘솔 로긴화면에 함께 보여줄 것이다. 아니면 간단히 /proc 디렉토리 밑을 보면 쉽게 알 수 있다.
[linux /lib/modules]$ cat /proc/version
linux version 2.2.0 (root@linux.korea.ac.kr) (gcc version 2.7.2.3) #3
fri feb 5 21:18:38 kst 1999
현재 시스템이 사용중인 커널이 2.2.0이라는 것을 보여준다. 결국 나머지 디렉토리들은 필요없는 디렉토리이다. 그러나 위의 커널은 본인의 시스템에 최적화 되어 있기 때문에 일반적이라고 볼 수 없다. 위의 디렉토리 중 2.0.36-1kr/은 레드햇 5.2a와 함께 제공되는 아주 일반적인 커널이므로 그 디렉토리 밑을 보도록 하자.
total 12
1 drwxr-xr-x 2 root root 1024 dec 18 23:55 block/
1 drwxr-xr-x 2 root root 1024 dec 18 23:55 cdrom/
1 drwxr-xr-x 2 root root 1024 dec 18 23:55 fs/
1 drwxr-xr-x 2 root root 1024 dec 18 23:55 ipv4/
2 drwxr-xr-x 2 root root 2048 dec 18 18:15 misc/
1 drwxr-xr-x 2 root root 1024 dec 18 23:55 net/
1 drwxr-xr-x 2 root root 1024 dec 18 18:15 pcmcia/
1 drwxr-xr-x 2 root root 1024 dec 18 23:55 scsi/
1 drwxr-xr-x 10 root root 1024 dec 18 23:55 ./
1 drwxr-xr-x 10 root root 1024 jan 27 19:04 ../
2 -rw-r--r-- 1 root root 1936 may 17 01:01 modules.dep
modules.dep 파일은 모듈정보를 담고 있는 파일이다. 저장장치(block, cdrom)이나 네트워크(ipv4) 그리고 하드웨어 장치(scsi, pcmcia, net)를 지원하는 모듈에서부터 파일 시스템에 대한 모듈까지 여러종류이다. 게다가 misc 밑에는 분류해 놓지 않은 많은 모듈들이 있다. 모듈들은 .o의 확장자를 갖는다. fs/ 디렉토리로 들어가 파일을 살펴보자.
[linux /lib/modules/2.0.36-1kr/fs]$ ls
total 533
15 autofs.o 5 nls_cp860.o 4 nls_iso8859_6.o
28 ext.o 6 nls_cp861.o 5 nls_iso8859_7.o
14 hpfs.o 6 nls_cp862.o 5 nls_iso8859_8.o
37 isofs.o 6 nls_cp863.o 4 nls_iso8859_9.o
34 minix.o 5 nls_cp864.o 5 nls_koi8_r.o
32 ncpfs.o 6 nls_cp865.o 42 ntfs.o
35 nfs.o 5 nls_cp866.o 35 smbfs.o
6 nls_cp437.o 5 nls_cp869.o 36 sysv.o
5 nls_cp737.o 5 nls_cp874.o 14 ufs.o
5 nls_cp775.o 4 nls_iso8859_1.o 29 umsdos.o
5 nls_cp850.o 5 nls_iso8859_2.o 20 vfat.o
5 nls_cp852.o 5 nls_iso8859_3.o 30 xiafs.o
5 nls_cp855.o 5 nls_iso8859_4.o
5 nls_cp857.o 5 nls_iso8859_5.o
여러 파일들이 있다. 이것들이 모두 모듈이다. file 명령을 이용하여 알아보면 다음과 같다. 참고로 알아두기 바란다.
[linux /lib/modules/2.0.36-1kr/fs]$ file vfat.o
vfat.o: elf 32-bit lsb relocatable, intel 80386, version 1, not stripped
모듈에 대해서 좀 더 알아보기 위해 디렉토리 별로 나뉘어져 있는 것을 따르지 않고 숨펌숨펑 나누어서 알아 보도록 하자.
8.1 하드웨어 지원
cdrom/ 에서는 일반적인 스카시나 ide 시디롬드라이브가 아닌 특정 인터페이스 카드를 요구하는 시디롬드라이브 지원에 대한 내용이 있다. net/과 scsi/는 각기 네트워크 카드와 스카시 카드에 대한 모듈들이다. pcmcia/는 당연히 pc카드 지원에 대한 내용이 들어 있다. 그밖의 하드웨어와 사운드 카드에 대한 모듈들은 misc/ 밑에 모아져있다.
8.2 네트워크 모듈 지원
ppp나 slip등 몇몇 네트워크 프로토콜등은 모듈로 지원되어 필요할 때만 그 기능을 사용할 수 있다.
8.3 파일 시스템
linux는 윈도우즈나 맥, 솔라리스등 다른 운영체제의 하드디스크 파티션을 읽고 쓸 수 있다. 이런 기능들은 매번 필요하지는 않을 것이다.
9. 모듈 사용하기
9.1 현재 올라와 있는 모듈 살펴보기
커널 1.2.x에 기초한 배포본을 사용하며 꾸준히 여러 패키지들을 업데이트 하며 시스템을 근근히 이어온 사람이 아니라면 대부분의 커널 2.x 대에 기초한 배포본에서는 이미 모듈을 사용하게 설정이 되어 있고 부지불식간에 그 모듈을 사용하고 있을 것이다. root로 로긴하여 /sbin/lsmod 라고 명령을 주어보자.
[root@linux artsilly]# /sbin/lsmod
module size used by
ppp_deflate 38516 1 (autoclean)
bsd_comp 3468 0 (autoclean)
serial 16860 1 (autoclean)
ppp 17744 2 (autoclean) [ppp_deflate bsd_comp]
slhc 4196 1 (autoclean) [ppp]
sb 30852 2
uart401 5628 2 [sb]
sound 55184 0 [sb uart401]
soundlow 240 0 [sound]
soundcore 2192 6 [sb sound]
[root@linux artsilly]#
위의 내용은 저자의 시스템에 오라와 있는 모듈이다. 간단히 살펴보면 아래쪽에는 사운드 블래스터 사운드 카드 모듈이 올라오면서 미디모듈이나 사운드 기초 모듈을 함께 올리고 있다. 또한 위쪽에는 ppp모듈이 올라오면서 ppp압축 알고리즘이나(bsd_comp) 시리얼 지원등의 모듈이 올라와 있다.
(autoclean)은 자동으로 필요할 때 모듈이 올라왔다는 의미이며 일정 시간이 지나면 모듈이 메모리에서 내려오게 된다. (autoclean) 플래그가 없는 모듈은 수동으로 올린 것이다.(사실은 매번 사운드카드 모듈을 올리기가 귀찮기 때문에 부팅 스크립트에서 올린다. 그렇다면 필요한 모듈을 올리고 또한 모듈을 메모리에서 제거하는 그런 명령을 알아보자. 자동으로 모듈을 올리는 명령을 알아보는 것은 추후 편한 사용을 위해 무척이나 유용하다.
9.2 모듈 올리기
모듈을 올리기 위해서는 모듈이 있는 디렉토리로 이동해야 한다.(실제로 몇몇 설정을 이용하여 모듈이 없는 디렉토리에서도 모듈 이름만을 가지고 올릴 수도 있다. 이것에 대해서는 추후 알아보도록 한다. 아래 예를 보면 모듈이 있는 디렉토리로 이동하지 않고도 모듈을 올린다. ^^ 거의 사기 수준이 아닌가?) 위의 사용중인 모듈 목록에는 플로피 드라이브 모듈(floppy.o) 이 올라와 있지 않으며 플로피를 사용하고자 한다면 플로피 드라이브 모듈을 올려야 한다.(물론 이 말은 사실이 아니다. 나의 시스템은 물론 자동으로 모듈을 올리도록 설정이 되어 있다. :-) root로 insmod floppy라고 해보자.
[root@linux /root]# insmod floppy
[root@linux /root]#
전형적인 유닉스 시스템의 유틸리티처럼 아무런 메시지가 나오지 않는다면 성공적으로 임무를 완수한 것이다. 다시 한번 lsmod를 이용하여 확인해보자.
[root@linux /root]# lsmod
module size used by
floppy 43864 0
ppp_deflate 38516 1 (autoclean)
bsd_comp 3468 0 (autoclean)
맨 위에 floppy라는 플로피 드라이브 모듈이 올라가 있음을 볼 수 있다. 몇몇 시스템에서는 설정에 따라 해당 모듈 디렉토리로 이동한 후에야 모듈을 올릴 수 있게 되어있기도 하다. 위와 같은 방법으로 모듈이 올라가지 않는다면 /lib/modules/2.0.36-1kr/block 등의 디렉토리 밑에 가서 모듈을 올리도록 하자.
몇몇 하드웨어는 옵션을 필요로 한다. 필자가 사용하는 랜카드는 자동으로 잡히지 않는 ne2000호환 isa 카드이다. 이 카드를 올릴 때는 옵션을 써 주어야 한다.
[root@linux /root]# insmod ne io=0x320 irq=10
위의 모듈은 표준출력으로 모듈이 올라갔음을 보여주는 몇몇 메시지들이 나오게 된다. io= 옵션을 많이 쓰게 되는데 이때 0x320과 같이 16진수 형식으로 표현해야 하는 것을 잊지 말도록 하자.
최근에 들어 종속구조를 갖는 모듈들이 생겨나며 그냥 모듈을 올리면 안되는 경우도 많다. 2.2.0대의 커널에서 프린터 모듈(lp.o)를 올리려하면 다음과 같은 에러가 난다.
[root@linux /root]# insmod lp
/lib/modules/2.2.0/misc/lp.o: unresolved symbol parport_unregister_device_r0ccf41c8
/lib/modules/2.2.0/misc/lp.o: unresolved symbol parport_enumerate_r6dea43fd
/lib/modules/2.2.0/misc/lp.o: unresolved symbol parport_claim_or_block_rfcbbf93d
/lib/modules/2.2.0/misc/lp.o: unresolved symbol parport_register_device_rac2401e9
/lib/modules/2.2.0/misc/lp.o: unresolved symbol parport_release_rb3370099
뭐 복잡한 에러가 나오지만 위의 말은 프린터 모듈이 올라가기 전에 패러렐 포트(프린터 포트) 모듈(parport.o)이 먼저 올라가야한다는 말이다. 프린터 모듈이 패러렐 포트 모듈을 참고하기 때문이다. 올바른 순서로 올리면 에러 없이 잘 올라간다.
[root@linux /root]# insmod parport
[root@linux /root]# insmod lp
[root@linux /root]#
lsmod 명령을 통해 위의 두 모듈이 잘 올라갔음을 볼 수 있다.
위와같이 종속적인 모듈의 경우 순서를 지켜서 올리는 것은 무척이나 귀찮고 번거로운일이다. 물론 이것에 대한 해결방안이 있다. 차츰 소개하도록 하겠다.
9.3 모듈 내리기
모듈이 필요 없어졌다면 당연히 모듈을 내려주어야 할 것이다. 이때 사용하는 명령이 rmmod이다. lsmod하여 보여주는 모듈을 rmmod를 통해 메모리에서 내릴 수 있다. 물론 여기에도 insmod와 같이 종속적인 모듈의 경우 먼저 내려주어야 한다. 아까 올렸던 프린터 모듈을 올리도록 하자. 우선 아까 올라간 프린터 모듈은 다음과 같다.
[root@linux /root]# lsmod
module size used by
parport_pc 5044 1 (autoclean)
lp 4280 0 (unused)
parport 6596 1 [parport_pc lp]
parport_pc는 pc용 패러렐 포트라는 또 하나의 모듈이다. 나의 시스템에선 이 모듈이 자동으로 올라가게 끔 설정이 되어있다.(물론 이렇게 자동으로 올리는 것은 나중에 잊지 않고 설명 할테니 걱정말기 바란다.) 보면 parport는 parport_pc와 lp에 의해 사용되고 있다. 모듈 제거는 parport 라인의 가장 왼쪽에서부터 지우도록 한다. 순서가 맞지 않으면 사용중이라는 에러메세지가 나오니 걱정하지 말고 지워질 때 까지 지우면 된다.
[root@linux /root]# rmmod parport_pc
rmmod: parport_pc: 장치나 자원이 동작 중
[root@linux /root]# rmmod lp
[root@linux /root]# rmmod parport_pc
[root@linux /root]# rmmod parport
[root@linux /root]#
순서대로 lp, parport_pc, parport를 제거했다. 맨 위의 명령처럼 parport_pc를 먼저 제거하려고 하면 에러가 난다. lsmod 해 보면 모듈이 지워진 것을 볼 수있다.
위에서 모듈을 올리는 것과 내리는 것에 대해 알아보았다. 그러나 무척! 귀찮다. 쉽게 그 모듈을 사용하고 싶을 때 자동으로 올리고 내려줄 수 있다면 무척이나 편할 것이다.
9.4 모듈 올리기의 자동화 1 - modprobe, depmod
사실 이런 내용은 모두 리눅스의 매뉴얼(man page)에 모두 나와있는 내용이다. 단지 영어라는 점만 다를 뿐이다. :) 잠시 modprobe나 depmod의 매뉴얼을 보자. 사실 두 명령은 같은 매뉴얼을 보여준다. 그만큼 두 명령이 밀접하기 때문이다. man modprobe를 통해 나온 내용은 아래와 같다.
depmod(1) linux module support depmod(1)
name
depmod, modprobe - handle loadable modules automatically
말 그대로 모듈을 자동화 시켜 올리는 도구이다. 사용법은 간단하며 내부 구조는 특별히 알지 못해도 무관하다. 먼저 depmod를 살펴보자.
depmod
depmod 명령은 위에 언급되었던 종속적인 모듈 관계에 대한 설정파일을 자동으로 생성해 준다. depmod -a 명령을 통해 /usr/lib/modules/커널버전/modules.dep에 설정파일이 생성된다. 이 파일은 일반 텍스트 형식이며 파일의 안은 간단하다. 위의 프린터에 관계되는 부분을 찾아보자.
/lib/modules/2.2.0/misc/parport_pc.o: /lib/modules/2.2.0/misc/parport.o
/lib/modules/2.2.0/misc/parport.o:
편집기에서 찾기등으로 찾아보면 될 것이다. parport_pc.o가 메모리에 올라가기 위해서는 parport.o가 먼저 메모리에 올라가 있어야 한다는 종속관계를 나타낸다. 물론 그 아래 라인의 parport.o는 아무런 종속관계가 없기 때문에 그 전에 어떤 모듈을 띄울 필요가 없다. 이번엔 lp.o를 찾아보자.
/lib/modules/2.2.0/misc/lp.o: /lib/modules/2.2.0/misc/parport.o
역시 lp.o도 parport.o에 종속되어 있다. 결국엔 메모리에 올리는 순서는 parport.o가 항상 먼저 올라와야 하고, 나머지 lp.o와 parport_pc.o는 나중에 올라와야 한다는 말이다. 이렇게 되면 lsmod 명령에서 설명하지 않았던 부분에 대한 해석까지 가능해 진다.
module size used by
parport_pc 5044 1
lp 4280 0 (unused)
parport 6596 1 [parport_pc lp]
[]에 묶여진 것은 parport.o 모듈에 종속되어 있는 두 모듈을 나타내 주는 것이다. 이제 모듈의 종속관계에 대해서는 알 수 있는 방법이 생겼으니 매번 이 파일을 참조해서 순서대로 모듈을 올려야 되는 것인가? 물론 그것조차 불편하다. 이 파일을 참조해서 자동으로 순서에 맞추어 모듈을 올려주는 명령이 modprobe이다. 그밖에 depmod 명령에는 버전을 명시하거나 특정 모듈에 대한 설정파일을 만드는 옵션이 있으나 그리 중요하지 않다. 일반적인 배포본에서는 매 부팅시마다 depmod -a 를 해주도록 설정되어 있다. 참고하고 싶다면 /etc/rc.d/rc.sysinit 파일을 보기 바란다.
modprobe
위의 종속적인 관계가 설정된 modules.dep 파일을 참조하여 모듈을 올리고 내리는 역할을 하는 명령이 modprobe이다. 위의 프린터 예로 돌아가보자. 단지 modprobe lp 라고 하는 것만으로 나머지 모듈들이 parport_pc와 parport 모두가 올라온 것을 볼 수 있을 것이다. 이 명령을 사용하면 다음과 같은 이점이 있다.
종속적인 모듈의 경우 순서를 자동으로 맞추어 준다.
종속적인 모듈을 메모리에 올리다가 실패한 경우 자동으로 부가적인 모듈들을 메모리에서 제거해 준다.
사용방법은 insmod와 같은 방법으로 사용하면 된다.
/etc/conf.modules
바로 위의 설명에 잘못된 점을 찾아낸 독자라면 무척 반갑다. 사실 위의 설명에는 오류가 있다. 즉 lp는 parport에만 종속되어 있는데 modprobe lp 명령으로 lp 모듈을 올리면 parport_pc 까지 올라오는 것이다. 이것은 modules.dep 파일 외에 모듈에 대한 설정을 하는 설정파일을 통해 이루어 진것이다. 설정파일은 /etc/conf.modules에 위치한다. 모듈별로 설정할 수 있는 내용이 있기 때문에 실제로 모든 모듈에 대해 설명을 한다면 그것 만으로도 책 한권 쓸 수 있을 것이다. 따라서 여기서는 예제를 통해 간단한 형식정도만 알아보고 자신이 쓰고자 하는 모듈에 대해서는 모듈 하우투 문서나 커널 소스의 문서 디렉토리 /usr/src/linux/documentation을 참고하여 모듈에 대한 설정을 하기 바란다.
alias parport_lowlevel parport_pc
alias sound sb
options opl3 io=0x388
alias midi awe_wave
post-install awe_wave /usr/bin/sfxload /etc/midi/gu11-rom.sf2
options sb io=0x220 irq=5 dma=1 dma16=7 mpu_io=0x300
options hisax type=20 protocol=2 id="hisax"
맨 윗줄을 통해 위에서 제기했던 궁금증에 대한 해답을 찾을 수 있을 것이다. parport 모듈은 하드웨어에 좀 더 밀접한 parport_lowlevel을 내부적으로 호출하게 되어있다. 그러나 parport_lowlevel은 각 하드웨어에 따라 여러 종류가 존재하므로 conf.modules에 우리가 쓰는 parport_lowlevel은 pc용 패러렐포트라고 알려줘야 한다. 그렇게 되면 modprobe에 의해 자동으로 메모리에 올리게 되는 것이다. 아랫쪽을 보면 사운드 카드에 대한 설정이 있다. 참고로 설정 방법은 무척 다양하므로 반드시 각 모듈의 문서를 읽어보기 바란다. 대강 살펴보면 사운드라는 이름으로 sb(사운드 블래스터카드 모듈)을 앨리어스 해 놓고 있다. 그리고는 본 저자의 사운드 카드는 pnp가 아니기 때문에 수동으로 사운드 블래스터의 하드웨어 설정 값을 알려주고 있다. 이때는 options라는 예약어를 이용한다. 이 예약어로 설정되었다면 매번 modprobe를 할 때 옵션을 써 주지 않더라도 자동으로 옵션 사항들이 들어가게 된다. 많은 하드웨어의 모듈은 io 어드레스와 irq에 대한 것들을 적어주어야 하는데 특히 io 어드레스는 0x320 이런 식으로 16진수로 써 주어야 한다는 것을 잊지 말자. 필자도 커널 2.0대를 처음 쓰면서 무심코 320 이렇게 썼다가 안된다고 온갖 자료를 뒤진 적이 있었다.
9.5 모듈사용의 자동화 - 2, 데몬, 스타트업
자 이제 모든 것이 끝났다. 자동으로 모듈을 올리도록 여러 설정을 마쳤다. 그러나 여기에서 마지막 고민이 생긴다. 사운드 카드나 프린터등을 정녕 필요할 때 modprobe 등도 사용하지 않고 자동으로 올리게 할 수 없을까? 그런 역할을 하는 것이 커널 데몬이다. 커널 2.0대에서는 외부 프로그램으로 kerneld라는 것이 있었으며 커널 2.2대부터는 커널 내부적으로 이 역할을 수행한다. 즉 지금 커널 2.2를 사용하고 있다면 커널 설정시 이 기능을 넣어주면 자동으로 필요로하는 모듈을 올리게 된다. 이런 메카니즘은 커널 내부적으로 이루어 진다. 때로는 이런 기능을 수행하기 위해 올바른 /etc/conf.modules 파일을 설정할 필요가 있다.(다시 한번 말하지만 모든 모듈에 대한 옵션들을 여기서 제공할 수 없다. 반드시 함께 제공되는 문서파일을 참고하기 바란다.)
마지막으로 스타트업 파일에 몇몇 설정을 빼놓지 않기 바란다. 위에서 한번 언급했지만 modprobe가 올바르게 동작하기 위해서는 모듈이 바뀔 경우 depmod -a를 해 주어야 한다고 했다. 레드햇에서는 스타트업 파일인 /etc/rc.d/rc.sysinit 파일에 이 내용을 넣어 놓았다.
if [ -x /sbin/depmod -a -n "$usemodules" ]; then
# get ready for kerneld if module support in the kernel
echo -n "finding module dependencies"
if [ -e /lib/modules/preferred ]; then
depmod -a preferred
else
depmod -a
fi
echo "done"
fi
위에서 보는 것과 같이 만일 /lib/modules/preferred 라는 디렉토리가 있다면 이 디렉토리에 있는 모듈에 대해 depmod를 수행하고 그렇지 않다면 현재 커널 버전에 맞추어 depmod를 수행한다. 일반적으로 /lib/modules/preferred는 현재 사용중인 커널 모듈의 소프트 링크이다. 물론 여러가지 방법으로 사용가능할 것이다.
그밖에 사운드 카드를 시작과 동시에 모듈로 올리는등 모듈에 대한 몇몇 스크립트가 있으며 사용자가 시작과 동시에 모듈로 올리길 바라는 모듈이 있다면 단순히 /etc/rc.d 밑에 rc.modules라는 파일을 만든 후 일반적인 방법으로 modprobe나 insmod등을 이용하여 적어주면 된다. 아래는 필자의 rc.modules이다.
modprobe hisax
위의 설정파일에보면 hisax에 대한 옵션을 찾을 수 있을 것이다. 참고로 hisax은 필자가 사용하는 내장 isdn 카드를 올리는 모듈이다.
10. 커널 설정을 위한 프로그램의 구동
사실 여기의 내용은 리눅스 커널 소스에도 그대로 담겨있는 내용이다. 대부분의 리눅스 개발자들은 자신의 프로그램과 함께 설치법을 친절하게 설명해 준다. 커널 역시 마찬가지이다. 물론 readme 파일은 읽지 않아도 좋은 거라고 생각하는 많은 사람들과 영어로 되어있는 readme 파일에 당황해하는 사람들을 생각해하면 있으나 마나 한 내용이라고도 할 수 있을 지도 모르겠다. 하여간. 커널 설정을 위한 내용이다. 위에 언급한 바와 같이 커널 설정에 대한 내용이 2.0.x대의 커널에 비해 약 2배 정도로 늘었고 그전 커널에 비해 설정내용이 무척 많다. 익숙하지 않은 옵션이라면 도움말을 잘 읽어보고 설정하기 바란다. 여기서는 커널 2.2.9에 대해 다루도록 하겠다. 최신버전의 커널은 2.2.12이다.
10.1 설정방법
make config
커널 설정 방법은 4가지가 있다. 아주 전통적인 스타일인 make config는 매 설정단계를 물어본다. 한번 선택하고 나면 어떻게든 뒤돌아 갈 수 없다. 설정가능한 값은 []에 묶여져 나오게 되며 디폴트로 정해져 있는 내용은 대문자로 표시된다. 중간 중간에 모르는 내용이 나오면 ?를 눌러 도움말을 볼 수도 있다. 일반적으로 설정가능한 값은 y(기능 추가), n(기능 제외), m(모듈로 추가)등이다. 모듈이 불가능한 기능의 경우 m이 표시되지 않는다. 물론 익숙하지 않다면 무척이나 불편하다.
make oldconfig
이 방법은 무척이나 유용하다. 매번 설정한 설정 파일은 /usr/src/linux 밑에 .config란 파일로 저장이 되는데 만일 이전 버전의 커널의 설정 파일이 있으며 새로운 버전의 커널에서 특별히 많이 바꿀 내용이 없을 경우(아마 대부분 그럴 것이다.) 이전 버전의 .config 파일을 새롭게 컴파일 할 커널 소스에 카피해 주고 make oldconfig를 해 주면 이전 설정을 그대로 따르며 새롭게 추가된 내용에 대해서만 질문을 한다. 커널 컴파일 광이 되려면 이 방법을 사용하는 것이 무척 유용하다. 만일 이전에 커널 컴파일 했던 설정이 있다면 한번 해보도록 하자. 이미 설정된 내용은 눈 깜짝할 사이에 스크롤되어 사라져 버리고 새로운 내용만 (new)라는 라벨을 달고 물어보게 될 것이다. 많은 시간을 절약해 준다.
make menuconfig
사실 make config는 초보자들에게 절대 권하고 싶지 않은 방법이다. 잘 알지도 못하는 커널 설정 내용을 물어보고 다시 되돌아 가서 수정하기도 힘들고 만일 내용 하나를 바꾸려 해도 모든 질문을 거쳐야지만 수정할 수 있다. make menuconfig는 이 설정 내용을 콘솔상에서 메뉴를 통해 쉽게 하도록 해 준다. 단 이 방법을 쓰려면 ncurse라는 라이브러리가 올바로 설치 되어있어야 한다. 자 make menuconfig의 화려한 화면을 보도록 하자.
tab을 눌러 맨 아래에 있는 명령을 선택가능하며 select에 놓은 채로 enter키를 누르면 각 하위 메뉴로 들어갈 수 있다. 상위 메뉴로 복귀는 tab을 이용해 exit에 놓고 enter를 누르면 된다. 방향 키를 이용하여 원하는 항목에 대한 설정을 할 수 있다. 각기 선택이나 제외는 항상 그렇듯이 y,n,m등이며 ?를 이용하여 도움말을 볼 수 있다. 메뉴를 이용하면 설정한 파일을 다른 이름으로 읽거나 저장할 수 있도록도 해준다. 맨 아랫줄에 있는 load an alternate configuration file, save configuration to an alternate file 이 그것이다. 이 방법을 이용하면 아주! 쉽다는 것을 느낄 수 있을 것이다. 앞으로 이 책에서는 이 방법을 이용하여 설명을 하도록 하겠다.
make xconfig
위의 make menuconfig를 x 환경에서 구현한 것이 make xconfig이다. 좀더 미려하고 편리한 인터페이스를 제공해 주며 마우스를 이용해 모든 기능을 작동시킬 수 있으며 사용방법이 직관적이다.
커널 2.0대를 컴파일 해 보았던 독자라면 달라진 메뉴에 잠깐 탄성을 지를 지도 모르겠다. 엄청나게 많아진 메뉴로 인해 세로로 나열했던 메뉴를 지금과 같이 3단으로 나누었다. 사용방법은 make menuconfig와 다르지 않다. 단지 마우스만 손에 쥐고 있으면 된다.
처음부터 다시 시작하고 싶을 때
커널을 컴파일 한 후 올바로 되지 않았을 경우 아예 새판잡이로 시작하고자 하는 사람이 있을 것이다. 이럴때는 가볍게 make mrproper라고 타이핑 해 주자. 모든 설정과 커널의 소스가 초기 상태로 되돌아 갈 것이다.
11.1 code maturity level options
사실 영어가 좀 된다면 쉽게 커널 옵션을 파악할 수 있을 것이다. 이 옵션은 아직 그리 안정적이지 않은 커널 코드이지만 이 코드를 쓰고자 하는 수요가 많기 때문에 들어와 았는 코드를 선택가능하게 할 것인가에 대한 옵션이다. 다른 메뉴들에 보면 가끔 experimental 이라 표시되는 옵션들이 있는데 이런 메뉴들을 선택하고 싶다면 이 옵션을 선택해 주어야 한다. 물론 그렇지만 이 옵션을 선택함으로 인해 생길 수 있는 모든 문제에 대해서는 아무도 책임을 지지 않는다. 정말 필요한 옵션을 사용하고자 할 때만 책임을 져야 할 것이다.
이 옵션을 선택할 경우 선택 가능한 옵션의 수는 거의 2배 가까이 늘어난다. 본 책에서는 이 옵션을 선택하지 않은 커널 컴파일에 대해 다룬다.
11.2 processor type and features
프로세서에 맞추어서 커널을 최적화 시킬 수 있다. 이것은 리눅스만이 갖는 또 하나의 즐거움이다. 펜티엄에 최적화 되어있는 코드를 사용한다는 것은 비록 현저한 속도 차이를 느끼지는 못하지만 그래도 기분은 좋을 것이다. 여기서는 인텔 호환칩(i386)에 대해서만 다루도록 한다.
processor family
리눅스는 386이상에서만 운용이 가능하다. 물론 xt나 at에서도 리눅스를 쓰고자 하는 사람들이 다양한 방법으로 xt와 at에 리눅스를 포팅했지만 기본적으로 386이상에서만 정식 리눅스 배포본이 사용가능하다. 선택가능한 옵션은 다음과 같다.
386
전형적인 386 머신
486/cx486
전형적인 486 머신
586/k5/5x86/6x86
아랫것과 비교해 볼때 최초의 펜티엄칩이나 그 호환 모델, 펜티엄 60등이 속한다.
pentium/k6/tsc
일반적인 펜티엄과 mmx 펜티엄, 리눅스에서는 mmx 펜티엄에 대해 어떤 최적화된 옵션도 제공하지 않는다.
ppro/6x86mx
펜티엄 프로, 펜티엄 ii, 펜티엄 iii와 그 호환모델
가끔 인텔칩 호환 모델 중에서는 386호환임에도 불구하고 486의 성능을 낸다고 하여 모델명중 486이라고 써 놓은 칩이 있다. cyrix/ti486dlc/dlc2과 umc 486sx-s 칩이다. 이런 칩을 사용할 때는 386을 선택해야 한다. 마찬가지로 cyrix 5x86등 펜티엄 호환칩이 아닌 486호환 칩은 반드시 486으로 선택해야 한다. cyrix나 amd등 인텔 호환칩 제조 업체를 위한 컴파일러 패치나 커널 패치등을 적용하면 좀 더 개선된 커널을 얻을 수 있을 것이다. 마지막으로 586과 pentium을 구분할 수 있어야 한다. 커널을 컴파일 하려면 물론 리눅스가 깔려있어야 하니까 간단히 리눅스 시스템에서 알아볼 수 있다. 586과 pentium을 알아보는 것은 tsc라 불리우는 time stamp counter의 여부에 달려있는데 아래 명령으로 cpu 정보를 알아보고 그 지원 여부를 알 수 있다.
[artsilly@kuls kernel]$ cat /proc/cpuinfo
processor : 0
vendor_id : genuineintel
cpu family : 5
model : 2
model name : pentium 75 - 200
stepping : 6
cpu mhz : 119.754508
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : yes
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8
bogomips : 47.82
/proc 디렉토리는 시스템의 정보를 파일화 해서 가지고 있는 디렉토리이다. 이 디렉토리의 cpuinfo라는 파일을 보면 cpu에 대한 정보를 알려준다. 위 정보는 필자의 동아리인 고려대학교 리눅스 동아리 메인서버의 정보이다. 펜티엄 120을 쓰고 있으며 인텔 칩이다. 밑에서 두번째 줄에 보면 flags라는 섹션이 있는데 이 줄을 보면 다섯번째에 tsc라는 단어가 보일 것이다. 따라서 이 시스템에서는 pentium을 선택해서 컴파일 가능하다.
가끔 펜티엄 호환 칩들은 커널을 컴파일 해야 하는 gcc나 커널 소스 일부를 패치해야 올바르게 컴파일이 되고 최적화 된다. 펜티엄 호환 칩을 사용하는 유저들을 확인하기 바란다.
math emulation
수치연산 보조 프로세서(math co-processor)가 없는 사용자가 선택해야 할 옵션이다. 일반적으로 486dx 이상에는 수치연산 보조 프로세서가 cpu에 함께 들어 있기 때문에 선택하지 않는다. 386이나 486sx 유저는 선택하도록 하자. 물론 추가 비용을 들여 387이나 487dx같은 수치연산 보조 프로세서를 메인보드에 달았다면 이 옵션은 사용하지 않는다. 만일 수치연산 보조 프로세서가 있거나 cpu 에 함께 들어있는 사용자가 이 옵션을 사용하면 시스템이 비 정상적으로 느려질 수 있다.
mtrr (memory type range register) support
펜티엄 프로나 펜티엄 ii 그리고 그런 호환모델들에는 mtrr이라는 레지스터가 들어있다. 이 mtrr은 agp나 pci 그래픽카드의 성능을 높여준다. cyrix 6x86, 6x86mx and mii 같은 호환 칩에는 mtrr과 비슷한 기능을 하는 arr이라는 레지스터가 제공되며 리눅스에서 호환된다. amd k6-2 일부 기종과 (위의 예제와 같이 cpuinfo를 봤을 경우 stepping이라는 섹션이 8 이상인 칩) k6-3에는 mtrr이 두개 내장되어 제공되며 이 역시 리눅스에서 지원한다. 그밖의 cpu를 사용하고 있다면 선택하지 않도록 한다.
symmetric multi-processing support
위의 말을 한글로 바꾸면 대칭형 다수 프로세싱이라 할 수있겠다. smp라 불리우는 기능은 한개 이상의 cpu를 동시에 사용할 수 있도록 해 준다. 흔히 불리우는 듀얼 cpu 보드나 4 way cpu 보드등에 2개나 4개의 cpu를 설치할 경우 os에서 여러 cpu를 사용할 수 있도록 지원해 주어야 하고 커널 2.2대의 가장 큰 기능이 이 smp 지원 기능이다.
486에서는 smp를 사용할 수 없으며 펜티엄 이상의 보드에서 smp를 사용할 수 있다. 일반 사용자라면 cpu를 두개 이상 설치하고 사용할 일이 별로 없으므로 n 를 선택하도록 하자. 만일 cpu가 두개라면 당연히 y이다. 그 밖에 특정 프로그램에서는 실제 cpu가 1개일 경우라도 smp 옵션을 선택하여 컴파일 된 커널에서만 돌아가는 경우가 있다. pc 자체를 에뮬레이션 해 주는 vmware등의 프로그램이 그런 부류이다.
cpu가 두개 이상이라면 커널 컴파일 도중에도 잇점을 얻을 수있다. 다음과 같이 /usr/src/linux/makefile을 수정하도록 한다.
as =$(cross_compile)as
ld =$(cross_compile)ld
cc =$(cross_compile)gcc -d__kernel__ -i$(hpath)
cpp =$(cc) -e
ar =$(cross_compile)ar
nm =$(cross_compile)nm
strip =$(cross_compile)strip
objdump =$(cross_compile)objdump
make =make -jn
^^^^
genksyms=/sbin/genksyms
위 코드는 makefile 윗쪽에 있다. 기본적으로 배포되는 커널 소스에는 밑줄친 부분이 없을 것이다. 자신의 cpu 숫자에 맞추어 -jn(n에는 cpu 수가 들어간다.) 옵션을 주면커널 컴파일시에도 좀더 이득을 볼 수 있을 것이다. 즉 cpu가 두개이면 -j2 네개이면 -j4와 같이 써 주는 것이다. 듀얼 펜티엄 2 400mhz 정도라면 이 옵션을 주고 커널 컴파일 하는데 약 2분 정도가 걸린다. 일반적인 펜티엄 120 에서 커널 컴파일이 30분 넘게 걸리는 것에 비하면 거의 제트기 수준의 속도라 할 수 있겠다.
11.3 loadable module support
이건 위에서 한참을 떠들어 댔기 때문에 누구나 쉽게 짐작을 할 것이다. 모듈에 대한 지원을 할 것인가 말 것인가에 대한 옵션이다. 아마 대부분의 사용자들은 모듈을 사용할 것이라고 생각이 된다. 모듈에 대한 장점은 위에서 한참을 이야기 했다.
enable loadable module support
이 옵션을 켜주도록 하자. 참고로 이 옵션을 n으로 선택하면 커널 설정 옵션 선택이 y(선택) n(선택하지 않음) m(모듈로 선택함)등으로 나오는 것도 모두 y와 n 만 선택하게 변해 버린다.
set version information on all symbols for modules
위의 모듈에 대한 설명에도 말했지만 이 옵션은 모듈에 커널 버전 정보를 넣는다. 그리고는 버전에 맞지 않는 모듈이라면 모듈을 올릴 수 없게 한다. 커널에 포함되지 않은 모듈을 사용해야 되는 사용자가 아니라면 이 옵션을 선택하고 안전(?)하게 쓰는 것이 좋다.
kernel module loader
커널 2.2대가 2.0과 다른 점을 보여주는 것 중 하나이다. 모듈 데몬인 kerneld가 없어지고 커널 스스로가 자동으로 모듈을 올릴 수 있도록 하는 기능이다. 만일 커널 2.0대에서 2.2대로 업그레이드 한다면 kerneld가 수행되지 않도록 /etc/rc.d 를 수정해 주는 과정이 필요하다. /etc/rc.d/디렉토리 밑의 kerneld 라는 단어가 들어간 모든 파일을 지우는 것으로 해결된다. 즉 /etc/rc.d/init.d/kerneld 나 /etc/rc.d/rc3.d/s0kerneld 등을 모두 지워준다.
11.4 general setup
본격적인 커널 설정부이다.
networking support
네트워크에 연결되어있지 않은 머신일 경우 이 옵션을 제외해도 되겠다는 생각을 할 지 모르지만 많은 경우에 이 옵션을 선택하는 것이 좋다. 리눅스의 많은 부분이 네트워크 지원 소스에 의존하고 있으며 전화접속을 통한 ppp 연결시에도 필요하다.
pci support
시스템이 펜티엄 이상이라면 당연히 pci 슬롯이 있을테고 이 옵션을 선택해야 한다. 이 옵션을 선택하면 추가 옵션이 나온다.
pci access mode
pci를 접근하는데 어떤 방법을 쓸 것인가를 선택한다. 일반적으로 시스템의 하드웨어는 바이오스를 통해 서비스된다.(bios 선택) 그러나 리눅스 시스템의 경우 바이오스를 거치지 않고 직접 하드웨어를 억세스 할 수있다.(direct 선택) 바이오스에 버그가 있는 경우에 특히 유용한 옵션이다. 많은 경우 하드웨어에 정통한 사용자가 아니라면 기본 설정값인 any를 선택하여 시스템이 여러가지 방법으로 하드웨어에 접근할 수있도록 하는 것이 좋다.
pci quirks
이 옵션 역시 바이오스의 문제를 바로잡아주는 옵션이다. 일반적으로 선택해주도록 하자.
backward-compatible /proc/pci
위의 예제에 한번 언급한 것처럼 /proc 디렉토리는 시스템의 정보를 파일로 저장해서 다른 여러 유틸리티가 사용할 수 있도록 해 준다. pci 카드의 정보는 커널 2.0대에서는 /proc/pci에 저장되었으나 커널 2.2대에서부터 /proc/bus/pci 에 저장되도록 바뀌었다. 그러나 아직 어떤 유틸리티가 /proc/pci를 참고할 지 확실하지 않기 때문에 구형 유틸리티와의 호환성을 위해 /proc/bus/pci와 /proc/pci를 두개 다 쓰겠다는 옵션이다. 세월이 지나면 이 옵션은 없어질 것이며 현재로는 커널 2.0대에서 2.2대로 넘어가는 과도기적 시절이므로 선택하도록 한다.
mca support
ibm ps/2 모델(현재 쓰고 있는 ps/2 마우스 등의 용어의 시발이 된 ibm의 386모델)에만 적용되었던 버스 형태인 mca를 지원한다. 대부분이 ibm ps/2를 사용하지 않을 것이고 ibm에서 mca에 대한 정보를 공개하지 않아 대부분 ibm 호환기종에서는 mca를 사용하지 않는다. 여하간 자신의 컴퓨터가 ibm ps/2가 아니라면 선택하지 않는다.
sgi visual workstation support
sgi는 실리콘 그래픽스 회사를 나타낸다. 갑자기 나타난 sgi 워크스테이션이라는 말에 당황했을 지 모르지만 ibm 호환기종의 컴퓨터 제작 업체중 이 실리콘 그래픽스의 칩셋을 이용하여 메인보드를 제작한 회사가 있다. 리눅스에서는 sgi 320과 540 칩셋을 지원한다. 참고로 이 보드가 아닌 시스템에서 이 옵션을 선택하면 커널이 부팅되지 않는다. 아마 대부분의 사용자가 이 옵션을 선택하지 않을 것이다.
system v ipc
ipc란 inter process communication이라 해서 컴퓨터에서 돌아가는 여러 프로세스들 간에 서로간의 주기를 맞추거나 정보교환을 위해 사용하는 여러 함수들의 집합이다. 리눅스 시스템은 대부분의 사람들이 유닉스 표준이라 생각하는 system v의 ipc 사용하며 이 옵션을 선택하지 않을 경우 심각한 문제를 일으킬 수 있다. 선택하는 것을 기본으로 하자.
bsd process accounting
이 옵션을 통해 프로세스가 생긴 시간이나 사용자, 메모리 상황, 터미널 상황등을 파일로 만들어 볼 수 있다. 시스템 관리나 여러 응용프로그램이 사용하며 선택하는 것이 좋다.
sysctl support
sysctl 인터페이스는 커널의 몇몇 인수들을 새로운 커널을 컴파일 하지 않고 적용할 수 있도록 해 준다. 일반적으로 시스템 콜이라 불리우는 시스템에서 주고 받는 메시지를 통해 운용되며 /proc/sys 디렉토리를 통해서도 설정 가능하다. 이 옵션에 대해 더 알고 싶다면 document/sysctl 파일을 참고하기 바란다.
kernel support for a.out binaries
여기서부터 나오는 3가지는 실행가능한 파일 포맷에 대한 것이다. 리눅스가 초기에는 a.out 형태라 불리우는 실행파일 형식을 사용했다. 그러나 지금은 elf라 불리우는 실행파일을 사용한다. 일반적인 배포본이나 자신이 직접 컴파일한 프로그램의 경우 elf로 제작된다. 오래된 실행 파일을 실행하고 싶다면 이 옵션을 켜 두는 것이 좋다. 커널 1.2 이하의 시스템에서부터 계속해서 업그레이드 해 온 사용자는 이점을 기억하기 바란다. 물론 이런 파일은 거의 없을테니 모듈로 지원하게 하는 것은 좋은 생각이다.
참고 kerneld 데몬이나 커널 2.2대의 커널의 경우 binfmt-4490(바이너리 포맷 4490)을 내부적으로 a.out 포맷과 연결시키므로 /etc/conf.modules 파일에 binfmt-4490을 binfmt-aout 모듈과 앨리어스 시켜주도록 하자. 즉 아래의 코드를 conf.modules 파일에 넣어 놓으면 a.out 포맷의 실행파일을 실행하면 kerneld 데몬이나 커널에서 자동으로 이 모듈을 올려준다.
alias binfmt-4490 binfmt-aout
kernel support for elf binaries
elf(excutable and linkable format, 실행 가능하거나 링크할 수 있는 형식)은 커널 1.2 이후로 등장했으며 여러가지 이유에서 a.out 형식에 비해 좋다.(왜 좋은지 대해서는 직접 찾아보기 바란다. 아마 전산 전공자가 아니라면 쉽게 이해하지 못할 말들만 잔뜩 써 놓았을 것이다.) 기본적으로 다른 시스템(비인텔칩등)에 포팅하기가 쉬우며 라이브러리 제작 역시 쉽다는 장점을 내세운다. 게다가 a.out에 비해 이름조차 멋있지 않은가?
현재 시스템이 elf를 쓰고 있다면 이 옵션을 반드시 선택해야 한다. 만일 이 옵션을 모듈로 선택하거나 선택하지 않는다면 시스템이 부팅되지 않는 경우도 있다.
kernel support for misc binaries
다양한 바이너리 실행파일에 대한 지원이다. 아직 지원 수준은 미약하지만 자바 바이너리를 지원하기도 한다. 이 옵션에 대해서는 도움말을 참고하기 바란다. 일반적인 사용자라면 선택하지 않는다.
parallel port support
커널 도움말은 이런 식으로 설명하고 있다.
"혹시 25핀을 가진 포트가 컴퓨터 뒤쪽에 달려있으며 혹시 프린터나 패러렐 연결 저장 장치등이 있다면 이 옵션을 선택해야 한다."
필자는 최소한 이 글을 읽는 독자들은 패러렐 포트가 무언지는 알고 있다는 생각이 든다. 패러렐 포트를 통해 무언가를 연결하고 싶다면 이 옵션을 선택해야 한다. 패러렐 포트는 우리말로 병렬 포트라고 하기도 한다. 이 옵션에는 부가 옵션이 있다.
pc-style hardware
몇몇 alpha 칩을 쓴 시스템과 모든 ibm 호환기종이 가지고 있는 프린터 형식이다. 대부분 인텔계열 즉 ibm 호환기종의 시스템을 사용중일 테니 프린터 포트를 올바로 사용하고 싶다면 이 옵션을 선택한다.
advanced power management bios support
요즘에는 apm기능이 구현되어 있는 시스템이 많이 있다. 이 옵션은 apm을 지원해 준다. 또한 atx 보드라면 자동으로 꺼지게 하는 옵션을 제공한다. 그러나 많은 이유에서 이 옵션은 노트북 사용자만 사용하기를 권장한다. 하부 옵션을 살펴보자. 물론 apm을 사용하기 위해서는 bios에서 apm 지원기능을 켜 놓아야 한다. 또한 몇몇 시스템에서는 바이오스 버그로 인해 반드시 옵션을 켜 놓아야 하는 경우도 있다.
ignore user suspend (new)
사용자의 시스템 잠시 멈춤(suspend) 요청을 거부하게 한다.
enable pm at boot time (new)
당연히 apm을 쓰자면 이 옵션을 켜 주어야 한다.
make cpu idle calls when idle (new)
이 옵션은 커널이 측정하는 cpu의 바쁜 정도를 apm으로 보내주어 좀더 많은 전원을 절약하게끔 해 준다. cpu의 idle 신호가 오면
enable console blanking using apm (new)
리눅스 콘솔(x 윈도가 아닌 텍스트기반 시스템)은 일정 시간이 지나면 화면을 까맣게 지워서 모니터를 보호한다. 이 옵션을 이용하면 몇몇 노트북 lcd의 백라이트를 꺼줌으로 배터리를 오래 쓸 수 있도록 해 준다. 몇몇 노트북만이 지원되는 기능이며 x 윈도에서는 아무런 기능도 해 주지 못한다.
power off on shutdown (new)
atx 보드등에서는 이 옵션을 통해 자동으로 컴퓨터의 전원을 꺼 준다. 대부분 apm을 쓰는 사람들은 이 옵션을 사용하기 위해 쓴다. 커널 2.2.4는 버그로 인해 이 옵션이 올바르게 작동하지 않기 때문에 이 버전의 커널을 사용하는 사용자라면 커널을 업그레이드 하기 바란다.
ignore multiple suspend (new)
말 그대로 동시에 여러 사용자나 여러 프로세스에서 suspend 요청을 할 경우 하나만을 인식하고 나머지는 무시한다는 말이다.
ignore multiple suspend/resume cycles (new)
이 옵션은 시스템이 suspend 상태로 들어간 바로 직후 사용자의 실수로 resume을 하는 경우 그 resume 요청을 무시하게끔 해 준다.
rtc stores time in gmt (new)
이 옵션은 gmt 즉 그리니치 표준시를 이용해서 rtc(리얼타임 클럭, 하드웨어 클럭)을 저장한다는 이야기이다. 별 필요가 없으며 bios의 문제로 인해 사용하게 될 경우도 있다.
allow interrupts during apm bios calls (new)
apm을 지원하는 바이오스에서 apm기능을 수행할 경우 인터럽트 요청을 관리하게 되는데 몇몇 기종에서는 올바르게 동작하지 않는 경우가 있다. 최근의 ibm thinkpad 에서 종종 이런 일이 있다고 한다. suspend를 수행할 경우 시스템이 죽어버리는 경우를 경험했다면 이 옵션을 주고 컴파일 해 보기 바란다. 일반적으로는 적용하지 않는다.
11.5 plug and play support
앗! 리눅스에서 pnp가 지원 되는구나! 라고 놀랄지 모르겠지만 아직 그 수준이 미약하다. 이 섹션 밑에는 똑같은 이름의 옵션이 있다. 이 옵션을 선택하면 커널에서 pnp 장비를 인식한다. 물론 너무 많은 기대는 하지 않는 것이 좋다.
11.6 block devices
block device란 저장장치를 말한다. 이 섹션에서는 리눅스에 붙일 수 있는 여러 저장장치들에 대한 지원 여부를 결정한다. 여기보면 쉽게 알아볼 수 있는 많은 옵션들이 있다. 익숙한 단어들을 사용했다고 마구 고르지 말고 신중하게 결정해서 자주 쓰지 않는 것들은 모듈로 선택하는 것이 좋다.
normal pc floppy disk support
플로피 디스크 드라이브를 지원하는 옵션이다. 당연히 지원해야겠지만 모듈로 지원하는 것이 더 좋은 생각이다.
enhanced ide/mfm/rll disk/cdrom/tape/floppy support
대부분의 개인사용자의 경우 하드디스크나 시디롬드라이브등의 장비가 ide 방식으로 연결되어 있을 것이다. 이 옵션은 이런 장치에 대한 지원 여부를 결정한다. 만일 scsi 장비만을 사용하는 유저의 경우에는 이 옵션이 필요 없을 것이다.
mfm/rll 등은 구형 인터페이스이다. at나 초창기 386에 설치되어 있다. 아마 대부분의 사용자는 이런 인터페이스에 대해 잘 알지못해도 된다. mfm/rll 하드 디스크는 이 옵션이나 이 아래의 old hard disk (mfm/rll/ide) driver (new) 옵션을 통해 모두 지원 가능하다. 그렇다면 왜 이렇게 두가지 방법이 있는 것일까? 우선은 구형 하드 디스크 사용자는 메모리도 적은 구형 시스템을 사용할 테고 ide와 mfm 모두를 지원 하는 드라이버에 비해 mfm 만 지원하는 드라이버의 경우 메모리를 적게 차지하는 장점이 있으며 두개 모두를 지원하는 드라이버의 새로운 기능은 어차피 쓸 수 없으므로 mfm/rll만 사용하는 사용자의 경우는 이 옵션 대신에 old hard disk(mfm/rll/ide) driver 만 선택하는 것이 좋을 것이다. 둘 다 사용하는 것은 물론 이 옵션으로 지원하게끔 해 주자.
use old disk-only driver on primary interface
위에 언급한 구형 mfm/rll 형식의 드라이브를 프라이머리 마스터, 즉 첫번째 드라이브로 설정할 때 사용하는 옵션이다. 대부분은 선택하지 않는다.
include ide/ata-2 disk support
당연한 이야기겠지만 ide 만을 사용하는 사용자라면 이 옵션은 반드시 선택해야 하며 모듈로 사용하는 것은 심각한 문제를 일으킬 수 있다. 단 scsi등의 장비에 시스템의 루트 파티션이 있을 경우 모듈로 선택가능하다. ide 드라이브로 부팅하고, 그 ide 드라이브에 루트 파티션이 있을 경우 절대로 모듈로 선택하지 않도록 한다.
include ide/atapi cdrom support
ata, ata-2는 고정형 장치(하드 디스크)에 대한 인터페이스이며 atapi는 이동형장치(cdrom, zip)등에 대한 인터페이스 이다. 시디롬 드라이브를 사용하려면 당연히 이 옵션을 선택 해야 한다. 그러나 시디롬의 경우 매번 사용하는 것이 아니므로 모듈로 선택하는 것도 좋은 생각이다.
include ide/atapi tape support
백업 장비인 테이프 드라이브 지원 여부이다.
include ide/atapi floppy support
최근에는 대용량 플로피 드라이브가 나오고 있으며 그런 것들은 iomega의 ide 방식 zip 드라이브나 imagtion의 ls-120등이 속한다. ide방식의 pd나 cdr등은 이 옵션으로 지원되지 않으며 아래 옵션에서 scsi emulation support 를 선택해 주어야 한다. 이것에 대해서는 추후 이야기 하도록 한다. 참고로 ide 방식의 zip드라이브 초기 모델의 경우는 ata-2 방식의 인터페이스를 사용하며 이 옵션에 관계없이 잘 잡힌다. 최근의 ide zip 드라이브의 경우 atapi 방식을 이용하여 이 옵션을 선택해 주어야 한다. 매뉴얼을 참고하기 바란다.
scsi emulation support
이 옵션은 pd-cd나 cdr등의 장비에 유용하다. 이 옵션을 선택한 후 scsi를 지원하도록 scsi emulation support 를 선택 해 주어야 한다. 이 옵션은 추후 scsi 섹션에 나오게 된다.
여러가지 chipset bugfix/support / other ide chipset support
비 표준이나 사용자가 적은 ide 칩셋등을 지원하는 옵션이다. 이런 옵션이 적용되는 시스템은 대부분 보드에 ide 칩셋이 내장되어 있는 펜티엄 이상의 보드이며 도움말에 보면 어떤 제조 업체의 어떤 칩셋을 쓴 보드에 이 옵션을 넣으면 좋다라는 형식으로 설명이 되어 있으니 메인보드 매뉴얼을 가지고 자신의 보드에 맞는 칩셋을 선택해 주면 된다.
generic pci ide chipset support
최근의 보드에서는 ide 인터페이스가 메인보드에 달려있다. 이 옵션을 이용하여 보드의 ide 인터페이스를 활성화 시킨다. 하부 옵션으로는 버스 마스터링 dma를 지원할 것인가등의 옵션이 있다. boot off-board chipsets first support 이 옵션을 선택하면 메인보드에 있지 않고 추가로 장착한 ide 인터페이스 카드가 첫번째 ide장치가 된다. 즉 일반적인 사항이라면 메인보드의 ide 인터페이스가 ide 0/1 이 되고 추가 ide 인터페이스 카드는 ide 3/4와 같이 되나 이 옵션을 선택하면 반대로 된다.
loopback device support
iso9660 시디 이미지나 플로피 디스크 이미지등 하나의 파일로 보이는 이미지 파일을 하나의 하드디스크 파티션처럼 사용할 수 있도록 해준다. 마운트 하고 파일의 내용을 확인해 볼 수 있다. 거의 대부분의 경우에 사용할 일이 없으나 이런 기능이 궁금하거나 리눅스에서 cd를 제작하는 사람들의 경우는 모듈로 지원할 수 있도록 해 주는 것도 나쁘지 않은 생각이다. 최근에 많은 배포본 제작 업체에서는 배포본 cd 이미지를 ftp등을 통해 공개하는데 이 옵션을 이용하여 cd 이미지를 하나의 cd처럼 쉽게 사용할 수 있다.
network block device support
tcp/ip 네트워크를 통해 다른 컴퓨터의 하드 디스크를 통째로 마운트 하여 사용할 수 있게 해 준다. 이 옵션은 클라이언트(마운트 하는쪽)에 대한 지원이며 /dev/nd0 등의 형식의 블럭 디바이스가 생긴다. 쉽게 생각하여 네트워크 드라이브 연결이라 할 수 있지만 nfs 나 coda 처럼 캐쉬를 사용한다든지 에러를 복구 해 준다든지 서버와 재 연결등의 개선된 네트워크 드라이브를 제공해 주진 못한다. 대부분의 경우에 사용하지 않는다.
multiple devices driver support
이 기능은 software raid 지원에 대한 이야기이다. raid는 물리적으로 여러개의 하드디스크를 하나로 쓰게 해 주는 기법이다. 즉 똑같은 내용을 여러개의 하드에 동시에 저장함으로 데이터 보관에 대한 신뢰성을 높여준다. 일반적으로 raid는 하드웨어로 제작된다. 그러나 소프트웨어로 raid를 지원할 수 있으며 리눅스 커널에서 지원한다. raid는 그 등급에 따라 raid-1/4/5 등으로 나뉠 수 있으며 등급이 높아질 수록 데이터 보관의 신뢰도가 높아진다. software raid 에 대한 사항은 software-mini howto를 참고 하기 바란다. 일반 사용자라면 그리 쓸 용도가 없을 것이다.
ram disk support
도스에서도 있던 기능이다. 램의 일부를 디스크처럼 쓰게 해 주는 기능이다. 이 기능은 리눅스 인스톨 시에 많이 쓰인다. 즉 램 디스크로 가상의 리눅스 시스템을 꾸미고 그 위에서 하드 디스크에 리눅스를 인스톨 하게 된다. 일반적으로 사용할 때는 별 사용 용도가 없다.
xt hard disk support
mfm/rll 보다 구형의 8bit 인터페이스의 xt 하드 디스크를 지원한다. 선택하지 않는다.
parallel port ide device support
많은 외장 cdrom이나 zip 드라이브같은 장비는 패러렐 포트를 통해 데이터를 전송한다. 이 옵션은 이런 외장형 장비를 지원한다. 만일 이런 패러렐 외장 장비와 프린터를 동시에 사용하고 싶다면 프린터 장치 옵션과 이 옵션을 모듈로 선택한 후 /etc/conf.modules 를 적당히 편집해서 자동으로 전환되도록 해야 할 것이다. 둘 중 하나라도 커널 내부에 들어가게 되면 하나의 장비는 아예 사용이 불가능하다. 이 옵션을 선택한 후 부가 옵션들은 자신의 장비에 적절한 것을 선택해 주도록 하자. 이 옵션은 그리 일반적이지 않으므로 독자 스스로 도움말을 읽어가며 선택하도록 하자. 물론 영어사전이 필요하리라 생각이 된다.
11.7 networking options
사실 커널 컴파일시 가장 이해 할 수 없는 옵션들이 이 네트워킹 옵션들일 것이다. 봐서도 무슨 말인지 모르겠고 도움말을 봐도 여전히 어렵다. 또한 한글로 되어있는 설명을 보아도 어려운 말이 너무 많이 나온다. 이해 못하는 옵션이 나올 경우 여러 문서를 참고하며 애해하도록 하자. 리눅스는 do it yourself 아닌가? 대학 교재로 쓰이는 네트워크 책등도 참고하는데 꽤나 쓸만하다.
네트워크 옵션은 특별히 잘 모르겠는 경우 기본으로 선택되어 있는 옵션을 사용하는 것도 무난하다.
packet socket
패킷 프로토콜은 프로그램이 디바이스를 직접 읽어오거나 쓸 경우에 사용한다. 이런 프로그램의 예로는 tcpdump 등이 있다. 이 옵션 역시 모듈로 선택가능하다. 확실하지 않은 경우 선택해 주도록 하고 선택이 기본 옵션이다.
kernel/user netlink socket
이 드라이버를 사용함으로 커널이나 모듈의 일부와 프로그램간에 양방향 통신을 가능하게 해 준다. 커널에서는 이 드라이버를 이용하여 몇몇 네트워크 정보를 출력해 주며(하부 옵션인 routing messages를 선택할 경우) 아래에 있는 ip: firewall packet netlink device 를 선택할 경우 firewall 코드에서도 사용한다. 또한 arp를 사용할 때도 이 옵션을 선택해 주어야 한다. 그밖에 자세한 것은 도움말을 참고 하기 바란다. 일반 사용자라면 기본값처럼 n을 선택해도 무방하며 내용을 잘 이해할 수 없다면 무난하게 y로 선택해 준다.
routing messages
위에서 말한것처럼 커널에서 라우팅 정보를 갖는 새로운 디바이스 /dev/route에 네트워크 정보를 써 준다. 이 디바이스를 읽음으로 네트워크 정보를 얻어낼 수 있다.
netlink device emulation (new)
예전 옵션과의 호환을 위해 있으며 곧 없어질 옵션이다. 우선은 y로 선택하도록 하자.
network firewalls
파이어월 기반에서 사용하고자 한다면 이 옵션을 선택하자. 단 이 옵션을 통해서는 packet filtering 기반의 파이어월을 지원한다. proxy based 파이어월은 커널과는 관계없이 사용가능하다.
socket filterling
특정 타입의 데이터를 소켓을 통해 보낼 것인가 말것인가에 대한 옵션이다. 소켓이 무엇이냐 묻는다면 점점 더 이 책의 내용이 방대해 지기 때문에 다른 책을 찾아보길 바란다. 선택하지 않도록 하자.
unix domain sockets
유닉스 도메인 소켓을 지원하기 위한 옵션이다. x윈도 시스템이나 syslog 같은 프로그램이 이 타입의 소켓을 쓴다. 모듈이나 커널 내장 방식으로 반드시 선택하도록 하자. 선택하지 않을 경우에 생기는 일에 대해서는 아무런 책임을 질 수 없다.
tcp/ip networking
인터넷과 랜환경에서 많이 쓰이는 프로토콜이다. 인터넷을 사용하고 싶다면(즉 www나 telnet, ftp등을 이용하고 싶다면) 이 옵션을 선택해 주는 것이 좋을 것이다. 그러나 말은 이렇게 했지만 인터넷을 사용하고 싶은 생각이 전혀 없더라도 이 옵션을 선택해 주는 것은 무척이나 권장할 만 하다. 커널 도움말이나 그밖의 리눅스 문서들을 보면 영어가 무척 좋아지는 경우가 있는데 이 옵션의 도움말 역시 맘에드는 구절이 나온다. 영어로는 short answer: say y. 구지 번역하자면 구구 절절히 생각하지 말고 선택하라고! 정도가 될 것 같다. 선택하자.
ip: multicasting
이 옵션을 통해 동시에 다수의 컴퓨터에게 패킷을 날릴 수 있게 한다. 일반 사용자라면 사용할 필요가 없다.
ip: advanced router
리눅스박스를 라우터로 사용하고 싶다면 선택하자. 라우터란 네트워크 패킷을 적절히 분배하거나 특정 위치로 보내주는 그런 기능을 하는 컴퓨터이다. 역시 다양한 옵션이 부가적으로 따라오나 이 기능을 사용하고 싶지 않은 많은 일반유저들에게는 그리 관계없는 옵션일 것이다. 선택하지 않는다. 만일 리눅스 박스를 라우터로 사용하고 싶다면 부가 옵션들을 잘 읽어보고 선택하자. 리눅스 라우터 프로젝트 를 방문해 보는 것도 많은 도움이 될 것이다.
ip: kernel level autoconfiguration
ip어드레스와 라우팅 테이블을 부팅할 때 자동으로 설정하고 싶다면 이 옵션을 쓰도록 한다. 자동 설정은 bootp나 rarp등의 프로토콜을 이용하여 수행된다. 이 기능은 디스크 없이 네트워크를 통해 부팅하고 네트워크를 통해 파일 시스템을 구성하는 경우에 유용하다. 일반적으로 선택하지 않는다.
ip: firewalling (new)
packet filter에 기반한 파이어월 장비로 리눅스 박스를 사용하고픈 사용자가 선택하게 된다. 일반 사용자라면 선택할 필요는 없을 것이다. 역시 리눅스 박스를 파이어월로 사용하고자 한다면 관련 문서를 주의깊게 읽어봐야 할 것이다. 커널 컴파일 도움말에서 시작하여 관련문서를 탐독하자.
ip: optimize as router not host
몇몇 리눅스 네트워크 드라이버는 성능향상을 위해 copy 와 checksum이라는 기능을 이용한다. 그러나 라우터로 리눅스 박스를 이용할 경우에는 이 옵션이 성능을 떨어뜨리는 주범이 된다. 이 옵션을 통해 위 기능을 끄게 되며 추후에는 다른 많은 최적화 기능이 소리 소문 없이 추가 될 것이다.
ip: tunneling
터널링은 다른 종류의 프로토콜을 통해 특정 프로토콜을 보내기 위해 해당 프로토콜을 통채로 잘 싸서 다른 종류의 프로토콜을 통해 보내는 기능이다. 이 기능이 필요하다면 선택하지만 아마 대부분 사용할 필요성을 니끼지는 못 할 것이다.
ip: gre tunnels over ip
터널링의 특별한 방법이다. 선택하지 않는다.
ip: multicast routing (new)
라우팅을 할 경우 멀티캐스팅을 통해 라우팅을 하겠다는 옵션이다. 여기서도 멋진 영어 한마디가 나온다. 도움말을 보면 이것에 대해 들어본 바 없다면 필요없는 것이다. 도움말대로 하자. 선택하지 않는다.
ip: aliasing support
하나의 물리적인 네트워크 디바이스에 여러개의 ip 주소를 할당가능하다. 종종 웹이나 ftp 서비스를 한 시스템에서 여러 호스트 네임으로 서비스 하기 위해 쓰인다. 보통은 멀티 호스팅이나 가상 도메인, 가상 호스팅과 같은 식으로 이야기 한다. 일반 사용자라면 선택하지 않아도 된다. 이 기능을 원하는 사람은 도움말을 읽어보고 선택하기 바란다.
ip: tcp syncookie support (not enabled per default)
일반적인 tcp/ip 네트워킹은 syn flooding이라는 공격에 노출되어 있다. 이 공격은 시스템 자원을 사용하지 못하게 하는 일반적인 공격(dos) 공격 중 하나이다. syn cookies는 이런 타입의 공격을 방어하기 위해 쓰인다. 선택하도록 하길 강력히 권고한다.
ip: reverse arp
rarp는 하드웨어 이더넷 어드레스는 알고 있으나 ip 어드레스가 유동적인 몇몇 하드디스크 없는 시스템이나 이동가능한 시스템의 ip를 찾아내기 위해 쓰이는 프로토콜이다. 디스크 없는 선 3 머신이 이런 방식을 사용했으며 리눅스에서도 이런 식으로 사용 가능하다. 역시 이것에 대해 아는 바가 없다면 선택하지 않도록 하자.
ip: allow large windows (not recommended if <16mb of memory)
네트워크의 효율을 높여주는 최적화 기법이다. 제목에 나온 것 처럼 16mb 이상이면 무조건 선택하도록 하자.
the ipx protocol
ipx 프로토콜은 노벨 넷웨어에서 쓰이는 프로토콜이다. 정확히 알지 못한다면 선택할 이유가 없다.
appletalk ddp
애플토크는 애플에서 쓰는 프로토콜이다. 애플과 연결하고 싶은 생각이 있다면 이 옵션을 선택하고 관련 문서를 읽어보기 바란다.
11.8 scsi support
스카시 장비에 대한 설정 사항이다. 위의 block device 설정의 ide 타입 저장 장치와 설정 내용이 비슷하다. 디스크와 테이프 드라이브, cdrom 드라이브등을 설정한다. 그밖의 스카시장비 - 스캐너나 씨디 라이터 등은 scsi generic support 를 선택한 후 각 장비의 설치법을 참고하기 바란다.
probe all luns on each scsi device
몇몇 장비의 경우 lun 이라 불리우는 논리적 유니트 번호를 가지고 있다. 씨디 체인저나 씨디 주크박스등의 장비가 그 대표적인 예이다. 이 옵션을 선택하면 모든 lun을 자동 검색하게 된다. 일반적으로 거의 쓰일 일이 없을 것이다.
verbose scsi error reporting (kernel size +=12k)
커널에서 내보내주는 스카시 장비의 에러메시지를 좀 더 알아보기 쉽게 출력해 준다. 위의 표시처럼 커널 사이즈가 12k byte 커지게 된다.
scsi logging facility
이 옵션은 /proc 디렉토리와 sysctl과 함께 컴파일 되어 스카시 장비의 문제를 조금이나마 수정할 수 있도록 하는 기능을 제공해 준다. 필요한 사람은 도움말을 참고하기 바란다. 일반적으로 선택하지 않는다.
scsi low-level drivers
스카시 카드등 드라이버를 선택하는 하위 메뉴를 활성화 시킨다. 자신의 스카시 장비의 모델명을 이용하여 적합한 드라이버를 선택한다. 여느 리눅스 하드웨어 드라이버가 그렇듯이 모든 드라이버가 올바르게 작동되는 것은 아니며 모든 하드웨어를 지원하지는 않는다. 만일 정식 배포본 커널에서 지원되지 않는 드라이버라면 인터넷등을 이용하여 개발중인 드라이버들을 테스트 할 수 있을 것이다. 리눅스의 드라이버를 개발한 개발자들 모두에게 고마운 마음을 갖지만 특히 스카시 드라이버를 제작한 개발자에게 특별히 고마움을 표시한다.
11.9 network device support
네트워크 장비의 드라이버에 대한 설정 옵션이다. 기본적인 이더넷 드라이버에서부터 토큰링, fddi 등의 드라이버가 존재한다. 이 역시 자신의 장비에 맞게 선택하기 바란다. 들어보지 못한 말은 거의 여러 장비에 대한 이야기이므로 특별히 설명하지 않도록 하겠다.
dummy net driver support
더미 넷 드라이버가 어떤 역할을 하는지에 대해 설명하는 것은 커널 컴파일에 대해 설명하기 보다는 네트워크에 대해 설명하는 것이 되므로 자세한 설명은 독자에게 맡기도록 하겠다. 문자 그대로 가상 드라이버며 slip 이나 ppp를 사용하고자 하는 사람은 이 옵션을 선택해야 한다. 모듈로 컴파일 되는 것을 추천한다.
eql (serial line load balancing) support
eql은 두개의 물리적인 회선으로 연결된 slip이나 ppp등의 시리얼 네트워크를 두배 속도의 하나의 회선을 사용하는 것처럼 사용하게끔 해 주는 기능이다. 일반적으로 이 기능을 이용하여 tt선 두개를 이용하여 2배 속도를 낼 수있게 된다. 이 역시 eql에 대한 것은 해당 문서를 읽어보기 바란다.
ethernet (10 or 100mbit)
가장 폭 넓게 쓰이는 네트워크 장비인 이더넷 드라이버를 선택하게 해 준다. 자신의 이더넷 랜카드의 제작회사나 사용 칩셋을 이용하여 적절히 선택하기 바란다.
fddi driver support
fddi는 광케이블 기반의 네트워크 프로토콜 디바이스이다. 역시 이런 타입의 디바이스를 사용하면 선택하도록 한다.
ppp (point-to-point) support
ppp는 시리얼 라인(모뎀 포함)을 이용하여 네트워크를 구성할 수 있게 하는 프로토콜이자 장비이다. 물론 ppp를 이용하는데는 물리적인 시리얼 장치인 시리얼 포트(rs232)나 모뎀등이 필요하다. slip은 ppp의 구버전이라 생각하면 된다. 요즘은 slip을 이용하여 서비스 하는 ip 업체가 그리 많지 않다.
11.10 amateur radio support
도움말에 보면 리눅스 박스를 아마추어 라디오와 연결 시키고 싶은 사람을 위한 옵션이라 써 있지만 일반 사용자에게는 그리 필요한 옵션이 아닐 듯 싶다.
11.11 irda subsystem support
irda는 적외선 무선 통신 장치이다. 일반적인 데스크탑에는 설치하는 예가 드물고 노트북에는 아마 다들 하나씩 달고 있는 장치일 것이다. irda를 이용하여 랜을 구성하거나 시리얼 포트처럼 쓰거나 가장 많이 쓰는 형식처럼 프린터 포트로 사용할 수 있는 여러 옵션들이 있다.
11.12 isdn subsystem
여기에서 선택하는 isdn subsystem은 내장형 isdn 장비에 대한 드라이버와 커널 지원 옵션들이다. 외장형 장비의 경우 일반적인 모뎀과 같이 사용하면 되기 때문에 이 옵션을 선택할 필요가 없다. 국산 isdn 내장형 장비의 경우 어떤 칩셋을 사용했는지 알기가 힘들고 호환 여부 역시 불투명 하므로 isdn 장비 구입에 신중을 기해야 한다. i&t 텔레콤에서 나온 스피드로 2000 과 같은 s-card는 hisax 칩셋을 이용한 netjet 카드와 호환이 된다. 각 카드의 호환 여부는 제조회사에 알아보기 바란다. 단 제조회사에서도 잘 모르는 경우가 많으므로 내장형 장비의 사용은 천운에 맡기든지 몇몇 검증된 장비를 사용하기 바란다.
11.13 old cd-rom drivers(not scsi, not ide)
여기에는 자체적인 하드웨어 장비를 이용하여 연결되던 구형 씨디롬 드라이브의 드라이버들이다. 즉 많이 사용되는 ide로 연결되는 atapi 씨디롬이나 scsi가 아닌 별도의 카드를 가지고 연결되던 소니나 파나소닉등의 시디롬을 말한다. 자신이 가지고 있는 장비가 있다면 선택하기 바란다. 일반적인 사용자라면 선택할 필요가 없을 것이다.
11.14 character device
여기에는 특별히 분류하기 어려운 여러 장치들을 모아놓았다. 시리얼 포트 지원이라든지 조이스틱 지원, tv 카드 지원등의 옵션이 있다.
virtual terminal
터미널이라 함은 모니터와 키보드로 이루어진 컴퓨터와의 기본적인 대화 통로라 보면 된다. 이 옵션을 선택함으로 리눅스 박스에 접근이 가능하다. 물론 이 옵션을 선택하지 않을 경우 텔넷 접속등의 방법을 통해서만 리눅스 박스에 접근할 수 밖에 없다.
support for console on virtual terminal
시스템 콘솔은 커널 메시지를 보여주거나 싱글모드로 들어갈 수 있도록 해주는 디바이스이다. 특별히 세상에 대한 원한이 없다면 선택하는 것이 좋다.
standard/generic (dumb) serial support
일반적인 시리얼 포트에 대한 지원 여부이다. 피씨의 시리얼 포트를 사용하고 싶다면 선택해야 할 것이다. 하부메뉴로 support for console on serial port 를 선택하면 시리얼 포트를 콘솔로 사용할 수도 있다. 이 하부 메뉴는 일반적인 선택사항은 아니다.
extended dumb serial driver options
시리얼 포트의 고급 설정이다. 메뉴에서 보는것과 같이 4개 이상의 시리얼 포트를 지원하거나 irq를 공유하거나 하는 등의 메뉴가 있다. 도스에서 말하는 com5등을 사용하는 모뎀을 이용하거나 그 밖의 여러 기술적인 문제를 해결 해 줄 수 있을 것이다. 사용자의 선택에 따라 달렸다.
non-standard serial port support
여기에는 피씨 시리얼 포트가 아닌 비표준 시리얼 포트 디바이스에 대한 지원여부를 결정한다. 이 역시 국내에서 시판중인 여러 시리얼 카드와의 호환성을 장담할 수 없으므로 잘 알아보고 구입하기 바란다.
unix98 pty support
pty란 pseudo terminal의 약자이다. 이 pty는 이전에는 bsd 타입의 pty를 사용했으나 여러 문제로 인해 unix98 표준에 맞는 pty로 바뀌게 되었다. 커널 2.2에 새롭게 들어온 내용이다. 선택하도록 하자.
parallel printer support (new)
말 그대로 패러렐 포트에 연결하는 프린터를 지원한다. 하부 옵션인 ieee1284를 선택하면 프린터의 정보를 읽어내는 양방향 통신이 가능하다.
mouse support (not serial mice)
시리얼 마우스가 아닌 다른 방식을 이용한 마우스 드라이버이다. ps/2 드라이버 역시 이 메뉴에 있으므로 ps/2 타입 마우스를 사용하려고 하면 선택하기 바란다.
watchdog timer support
와치독이란 경계를 서는 개를 말한다. 와치독 타이머는 와치독 데몬과 함께 쓰이며 어떤 상태를 감시하고 있다가 주어진 요건에 맞는 상황이 오면 특정 작업을 수행해야 하는 경우에 쓰인다. 일반적으로 선택하지 않는다.
dev/nvram support
nvram은 지워지지않는 램이며 전기가 없으면 내용이 지워지는 램과 달리 배터리를 이용하여 그 내용을 보존한다. 많이들 피씨 보드에 수은 건전지 같은 것이 붙어있는 것을 봤을 것이다. 흔히 이것을 cmos-ram이라 부르며 cmos의 정보를 저장하는 램이다. 이 램을 하나의 디바이스처럼 사용하여 cmos의 정보를 편집하거나(특정 유틸리티와 함께) 빈 공간에 몇몇 정보를 저장할 수도 있다. 일반적으로 선택하지 않으며 관심이 있는 사람은 문서를 참고하기 바란다.
enhanced real time clock support
이 옵션을 이용하면 시스템의 rtc를 하나의 디바이스로 만들어준다.
video for linux
리눅스에서 지원하는 tv카드를 지원하는 디바이스 드라이버이다.
11.15 filesystems
이 섹션에서는 리눅스에서 지원하는 파일 시스템에 대한 지원이 나와있다. 리눅스에서는 여러 다양한 os에서 쓰이는 파일 시스템을 읽거나 쓸 수 있도록 해 준다.
quota support
쿼타란 하드디스크의 사용량을 사용자에 맞추어 제한 해주는 기능이다. 개인적으로 사용하는 리눅스 박스에서는 그리 필요없는 옵션이나 다수의 사용자가 사용하는 하드디스크의 경우에는 한 사용자의 과다한 하드 디스크 사용을 막기위해 쿼타를 설정해 주는 것이 좋을 것이다.
kernel automounter support
이 옵션은 nfs등의 원격파일 시스템을 사용자의 요구에 따라 자동으로 마운트 해주는 기능을 커널에 추가해 준다. 일반적으로 선택하지 않는다.
amiga ffs filesystem support
아미가의 파일시스템을 읽고 쓸 수 있도록 해 준다.
dos fat fs support
도스의 파일 시스템을 읽고 쓸 수 있게 한다. 하부 옵션으로는 윈도우즈 95 이상에서 쓰이는 vfat 파일 시스템의 지원과 일반적인 도스에서 사용하는 fat 지원으로 나뉜다.
iso 9660 cdrom filesystem support
씨디롬의 표준 파일 시스템이다.
microsoft joliet cdrom extensions
졸리엣이라는 마이크로 소프트에서 지원하는 유니코드를 이용한 긴 파일이름을 지원하는 씨디롬의 확장 파일 시스템이다.
minix fs support, ntfs filesystem support (read only), os/2 hpfs filesystem support (read only)
각각 미닉스와 nt, os/2의 파일 시스템을 사용할 수 있게 해 준다.
/proc filesystem support
/proc 디렉토리는 시스템의 정보를 가상의 파일로 저장해 여러 프로그램에서 쉐어링 하는 용도로 쓰인다. 특별히 어떤 용도로 쓰이는지 몰라도 이 옵션만큼은 선택하는 것이 건강에, 신상에, 나라에 도움이 된다.
/dev/pts filesystem for unix98 ptys
위에 한번 언급한 unix98 pty를 디바이스로 사용하여 마운트가 가능하도록 하는 옵션이다. 여기에 대해 관심이 있는 독자는 문서를 참고하기 바란다. 일반적으로 선택하지 않는다.
rom filesystem support
롬을 이용하여 부팅하거나 시스템을 꾸민 상황에서 사용하는 파일 시스템이다. 거의 모든 경우에 사용하지 않을 것이다.
second extended fs support
때려 죽여도 이 옵션만큼은 선택하도록 하자. 특히 자신의 시스템이 ext2 파일 시스템으로 포맷 되고 사용중이라면 더욱 그렇다.
system v and coherent filesystem support
스코 유닉스나 제닉스에서 쓰이던 파일 시스템을 지원한다.
ufs filesystem support
bsd나 sunos, nextstep 등에 쓰이는 파일 시스템이다.
network file systems
유용하게 쓰이는 네트워크 파일시스템의 지원여부다. 특히 2.2대 커널에서는 nfs 뿐 아니라 coda, smb(윈도우즈 네트워크 파일 시스템)등을 지원한다.
patition types
특별한 파티션 타입을 인식하기 위한 옵션이다. 많은 사람들이 이 옵션에 대해 깊이 생각하지 않아도 될 것이다.
native language support
nls는 마이크로 소프트의 파일 시스템 세트(fat, joliet, ntfs등)에서 다국어를 지원하기 위해 구성되어 있다. charset과 도스에서 기원한 codepage를 자신의 나라에 맞게 적절히 선택해 주어야지만 그 나라의 자국어를 사용할 수 있다. 우리나라는 codepage 949와 charset euc-kr을 사용한다. 그러나 커널을 새로 받았다면 절대 이런 옵션은 없을 것이다. 새로운 커널이 나올 때 마다 통신망등을 이용하여 패치 파일을 받아다 패치를 해 주어야만 한국어를 볼 수 있을 것이다. 이것이 귀찮다면 한글 패치된 패포본의 커널 소스를 사용하는 것도 권장할 만하다. 한글 패치는 여러 통신망등에서 구할 수 있으며 모든 커널 버전에 맞는 패치가 있는 것은 아니라는 것을 명심하기 바란다. 각 한글 패치의 사용법은 패치에 따라 다르니 패치를 다운받은 곳에서 확인하기 바란다.
11.16 console drivers
일반적으로 콘솔(터미널은) bios 문자 입출력을 기반으로 하여 구성되었다. 즉 리눅스 콘솔과 dos의 모습은 거의 다를 바 없이 80x25라인의 영문 텍스트를 사용하는 화면으로 보여진다는 말이다. 그러나 시대가 발전하고 그에 따라 커널 2.2에서는 그래픽 콘솔을 지원하여 좀 더 해상도 높은 콘솔화면을 사용할 수 있도록 해 준다.
vga text console
일반적인 텍스트 콘솔의 지원이다.
vga mode selection support
이 옵션을 통해 lilo나 loadlin등의 부트로더에서 vga= 라는 옵션을 통해 vga의 몇몇 해상도를 선택할 수 있도록 해 준다.
11.17 sound
리눅스에서 사용할 수 있는 사운드 카드 목록이 주르륵 주르륵 나오게 된다. 대부분의 널리 쓰이는 사운드 카드는 oss sound modules 밑에 나오게 된다. 모듈이나 선택으로 적절히 사운드 카드를 설정할 수 있지만 모듈로 선택하는 것이 좀 더 유용하다.
11.18 kernel hacking
magic sysrq key 라는 옵션을 통해 시스템이 다운되었을 경우에도 특정 키 조합을 통해 시스템에 접근 할 수 있도록 해 준다. 모든 경우에 사용 가능한 것은 아니며 개발 버전의 커널 사용시나 커널 디버깅시 유용하게 사용가능하다.
이제 길고 긴 설정 과정이 끝났다. 위의 설명은 충분치 않으며 각각의 옵션에 대한 개략적인 정보만을 담고 있으므로 각 옵션에 대한 배경지식과 좀 더 많은 공부를 통해 자신에게 적함한 커널에 좀 더 가까워 진다고 할 수 있을 것이다. 이제 설정이 바르게 되었는지 한번 더 검사한 후 exit를 통해 빠져나온다. 그러면 설정을 저장할 것인가 하는 질문이 나온 후 /usr/src/linux/.config라는 파일로 저장이 된다. 이제 설정이 끝났다. 설정이 끝나고 나오면 여러 방식으로 그다음 과정에 대해 설명해 준다. 이제 해야 할 일은 눈에 보이는 것 처럼 여러 소스들의 의존성을 검사하고 커널을 컴파일 하기 위해 깨끗이 기존 컴파일된 정보를 지우기 위해 make dep과 make clean을 해 주는 것이다.
이제 커널을 컴파일 한다. 커널을 컴파일 하는 방법은 몇몇 가지가 있다.
13.1 make zimage
커널을 만드는 가장 평범한 방법중 하나이다. 이렇게 컴파일 된 커널은 /usr/src/linux/arch/i386/boot/zimage 라는 이름으로 생성이 되며 이 커널 이미지를 적절히 이용하여 부팅 가능하다. 추후 과정은 이 방법을 기준으로 설명하도록 한다.
13.2 make zdisk
디스크에 만들어진 커널 부트 이미지를 바로 심어준다. 플로피를 a:에 넣어주고 수행한다.
13.3 make zlilo
lilo의 설정이 올바로 되어있으면 make zlilo를 통해 수동 과정을 자동으로 해주는 스크립트를 수행한다.
13.4 make bzimage
커널이 클 경우 커널을 좀 더 압축해 준다. 커널 2.2 대에서는 make zimage 보다 이 방법이 좀 더 권장할 만 하다.
이제 기다리자. 커널이 컴파일 되는 것은 시스템 성능에 따라 다르지만 최대 4시간에서 2분정도 걸린다. 386에 램 4메가 정도라면 밖에서 농구 한판, 게임 한판, 밥 2끼 정도 후에 들어와도 좋고 펜티엄 iii 듀얼 정도라면 잠시 눈 감았다가 눈을 뜨면 컴파일이 되어 있을 것이다.
이제는 모듈을 컴파일 한다. 모듈 수에 따라 다르지만 이 역시 커널 컴파일 하는것 만큼 시간이 걸린다. 아래 명령으로 수행하자.
make modules
시스템의 속도가 느려서 커널 컴파일과 모듈 컴파일을 걸어놓고 어딘가 갔다오거나 잠을 자려 한다면 make zimage; make modules와 같이 ;을 이용하여 두 명령을 한번에 수행시켜놓고 가는 것도 좋은 생각이다.
물론 커널 컴파일시 생길 수 있는 에러에 대처하기 위해서는 컴퓨터 앞에 지켜보는 것이 좋다.
위의 모듈 설명에 나온 것 처럼 모듈은 /lib/modules 밑에 있어야 한다. 모듈 인스톨 과정은 이 일을 해준다. 그런데 해당 커널 버전에 대해 이미 컴파일 해 놓은 모듈이 있을 경우 커널에 추가되지 않은 모듈과 섞이게 되므로 이 경우에는 기존의 모듈을 지워준다. 즉 /usr/modules 밑에 2.2.10 모듈이 존재한다면 이 모듈 디렉토리를 지우거나 다른 이름으로 백업시켜 놓고 모듈을 인스톨 하도록 한다.
make modules_install
모듈까지 설치 했다면 커널 컴파일이 끝났다. 그러나 이것으로 바로 새로운 커널로 부팅할 수 있는 것이 아니다. 위에 말한 것 처럼 적합한 lilo의 설정과 make zlilo 명령으로 커널을 컴파일 하지 않았다면 커널 이미지는 단지 하드 디스크의 하나의 파일로 존재할 뿐 부팅과는 관계없다. 이제는 lilo나 loadlin 설정을 이용하여 새로운 커널로 부팅할 수 있도록 해야 한다.
자 이제 새로운 커널로 옷을 갈아입자. 우선은 일반적인 리눅스 시스템에서 사용하는 방식대로 /usr/src/linux/arch/i386/boot/zimage를 /boot로 복사하도록 한다. 물론 make bzimage로 만들었다면 bzimage를 복사해야 할 것이다. 보통은 zimage라는 이름보다는 전형적으로 vmlinuz라는 이름을 선호한다.
# cp /usr/src/linux/arch/i386/boot/zimage /boot/vmlinuz
이 역시 이 이름을 사용하는 이전 커널이 있다면 이전 커널을 적당한 이름으로 복사하자. 이전 커널이 2.2.1과 같은 버전을 같는다면 vmlinuz-2.2.1과 같은 식으로 바꾸거나 vmlinuz.old와 같은 식으로 바꾼다면 이해하기 쉬울 것이다.
또 하나의 파일은 여러 시스템 툴에서 사용하는 system.map 파일을 복사하는 것이다.
# cp /usr/src/linux/system.map /boot
이제 lilo 설정으로 넘어가자.
16.1 lilo 설정하기
lilo는 /etc/lilo.conf 파일을 통해 설정된다. lilo 설정 역시 다양한 옵션이 있으며 거기에 대해서는 lilo-howto등의 문서를 참고하고 여기서는 간단한 세팅만을 다루도록 한다.
아래는 /etc/lilo.conf의 예이다.
boot = /dev/hda
vga = normal
read-only
map=/boot/map
install=/boot/boot.b
prompt
timeout=5
image = /boot/vmlinuz-2.0.36-3kr
label = linux
root = /dev/hda1
위의 여러 옵션에 대해서는 특별히 신경쓰지 말고 image = 옵션을 보자. 지금은 리눅스 배포본에서 제공하는 기본 커널이 linux 라는 라벨을 가지고 있다. 여기에 우리가 만든 커널을 새롭게 추가하면 된다.
boot = /dev/hda
vga = normal
read-only
map=/boot/map
install=/boot/boot.b
prompt
timeout=5
image = /boot/vmlinuz
label = linux
root = /dev/hda1
image = /boot/vmlinuz-2.0.36-3kr
label = old
root = /dev/hda1
바뀐 부분을 보자 우선은 우리가 작성한 커널을 디폴트로 하기 위해 기존에 있던 이미지 위에 놓았다. image = 는 당연히 새롭게 복사한 /boot/vmlinuz가 되고 이 것의 라벨을 linux로 대체하였다. root = 에는 루트 파일시스템이 놓여있는 디바이스를 써준다. 기존의 이미지는 label 만 old로 바꾸어 주었다. 물론 안심할 수 있다면야 아래 image = 을 지워도 좋겠지만 만일 새롭게 컴파일한 커널이 부팅이 되지 않는다면 어쩔 것인가? 만일 부팅 디스크도 없다면 친구집에 가서 부팅 디스켓을 만들어와야 하는 수고를 덜어줄 최후의 안전망이 될 것이다. 부팅 디스크가 있다면 구지 오래된 커널 설정을 둘 필요는 없지만 위와 같이 해 주는 것은 여러가지 상황에 권장할 만 하다. 앞으로 새롭게 컴파일한 커널을 linux 기존 커널을 old라 부른다.
마지막으로 /sbin/lilo를 수행시켜 줌으로 lilo.conf에서 설정한 내용을 반영시켜주어야 한다. 처음 커널을 컴파일 할 경우에 lilo를 수행하는 것을 빼먹고 "왜 새로 부팅한 커널이 수행이 안될까?"라고 의문을 갖는 경우가 허다하다. lilo를 빼먹지 말자!
lilo를 수행하면 다음과 같은 메시지가 나올 것이다.
[root@kuls /boot]# lilo
added linux *
added old
linux와 old가 올바르게 설치되었다는 말이며 linux 옆의 * 표시는 이 이미지가 디폴트 부팅 이미지라는 것이다. 이제... 부팅하면 새로운 커널이 반결 것이다.
16.2 loadlin.exe
자 도스에서 쓸 수 있는 loadlin에는 멀티 부팅이 없다. 그때 그때 써 주면 된다. 지금 컴파일한 커널을 도스 영역에 복사를 해놓자. 임의로 c:\linux\ 에 복사를 한다고 생각하자. 물론 여기서는 어떻게 도스 영역에 복사하는지에 대해서는 다루지 않겠다. loadlin에도 여러 옵션이 있지만 리눅스를 부팅하기 위해서는 단지
c:\linux>loadlin vmlinuz root=/dev/hda1
와 같이 해주면 된다. root= 는 위의 lilo.conf의 옵션과 같은 의미이다. 이 역시 도스 영역에 기존 커널이미지도 복사해 두고 만일의 사태에는 기존 커널 이미지로 부팅 가능하게 해 주는 것이 좋다.
17.1 으악... 커널 패닉?
커널이 올바로 컴파일 되지 않았다면 시스템 부팅중에 kernel panic이라는 메시지를 내고 시스템이 죽어버린다. 이것은 컴파일 옵션이 잘못 설정된 것이다. 재부팅후 lilo: 프롬프트가 뜨면 old라고 타이핑해 우리의 안정망인 구형커널로 부팅한 후 다시 위의 과정을 수행해야 한다.
17.2 새로운 모듈의 추가
새로운 모듈의 추가는 커널 설정을 다시 한 후 make dep; 만을 한 후(make clean까지 하면 안된다.) make modules, make modules_install을 수행해 주면 된다. 그 이후에는 새로운 모듈 정보를 갱신하기 위해 depmod -a 를 해 주고 사용하면 모듈이 추가 된다. 다시금 커널을 컴파일 할 필요도 없으며 make modules 과정 역시 새로운 모듈만을 컴파일 하기 때문에 빠르게 진행된다.