[ 허준의 커널 컴파일 보감 ] 작성일 : 2000년 6월 25일 갱신일 : 2000년 10월 28일 작성자 : 류종훈 (queenrjh@chollian.net) # 이 번에 새로 갱신된 이 문서에서는 "커널 옵션 한글화 프로젝트(http://kernel.pe.kr)" 에 주 인이신 정원영님의 "커널 2.4 Intro" 글 중에서 일부분 인용했음을 알려드립니다. 또한, 데비안 에 관한 약간의 내용및 노트북 사용자들을 위한 내용과 그 밖의 내용이 추가및 수정 되었습니다. 리눅스를 어느정도 사용한 사용자라면 커널 컴파일이라는 것을 접하고, 이에 빠지면 중독증 환자 가 되어 버리는 것을 종종 목격하게 됩니다. 하지만, 처음 컴파일 하는 사람이나 어느 정도 맛을 본 사람도 프로그램밍을 할 줄 알거나 시스템에 대해 어느정도 알고 있는 사람이 아니라면, 마치 무슨 주문도 같은 명령을 내려 자신만의 우월함을 과시하듯 컴파일 시에 화면에 출력되는 메세지 를 즐겁게 바라보고 있는 리눅스 마법사를 초보자들은 옆에서 부러움으로 넋을 잃고 보게 됩니다. 저 또한 많은 것을 알고 있지는 않지만, 그런 심정을 느끼는 분 들에게 도움이 되고자 쓰게 되었 습니다. 그리고, 간혹 참고할 만한 글을 읽다 보면 '이 부분은 다른 글을 참고하세요..' 라는 것 이 굉장히 불편했던 기억을 되살려 이 문서에는 되도록 그런 말을 하지 않도록 했습니다. 어쨌든, 이 글이 커널 컴파일에 대해 모든 것이라고 말하지는 않습니다. 하지만, 많은 분들에게 여러 리눅스 마법사들의 주문(?)을 조금이나마 알아 듣기위한 번역서가 되길 바랍니다. ------------------------------------------------------------------------------------------ * 이 글은 rpm 과 deb, 그리고 소스로 커널 컴파일 할 때의 세가지 경우 모두 설명 하겠습니다. 커널 컴파일에 관심이 있어 그에 관련된 글을 읽어 보셨거나, 한 번이라도 커널 컴파일을 해보 신 경험이 있으신 분들을 위한 글입니다. 처음 커널 컴파일 할 때의 각 명령의 내용이 이해가 안가셨던 분들이나, 명령을 무작정 외워서 커널 컴파일 하셨던 분들은 이 글이 아주 많은 도움 이 되실겁니다. ------------------------------------------------------------------------------------------ >> 항상 그렇듯, 먼저 커널의 개요와 컴파일의 필요성에 대해 아주 간략히 설명을 하겠습니다. 커널이란 운영체제의 가장 핵심을 이루는 부분입니다. 도스에서는 IO.SYS 와 MSDOS.SYS 이 그에 해당하고, 윈도우즈에서는 kernel32.dll 라는 파일이 기본적인 장치들의 구동과 입/출력을 담당 하는 부분이라는 것을 아시는 분은 다 아실겁니다. 일반적인 리눅스 배포판의 커널은 여러 다른 많은 종류의 하드웨어와 상당수의 설정들을 지원 해 야 하기 때문에 커널의 크기가 커지고, 사용하지 않는 기능이 많이 추가 되었으므로 자신의 시스 템에 최적화되지 못해 퍼포먼스가 다소 떨어집니다. 이런 경우 필요한 사항만으로 커널을 컴파일 해서 불필요한 기능들을 모두 제거하면 커널이 상당히 작아지고 성능에도 많은 향상을 가져올 뿐 만 아니라 기본 배포판에서는 없는 기능을 새로 추가할 수도 있습니다. 더구나 리눅스는 커널 소스가 공개되어 있기 때문에 최신 버젼의 소스를 가져와서 자신의 시스템 에 최적화하여 사용할 수 있다는 것도 아주 매력적인 일 입니다. 커널을 소스로 가져올 수 있는 공식 사이트는 ftp://ftp.kernel.org/pub/linux/kernel/ 입니다. 이 디렉토리 안에는 여러 버전 의 디렉토리들이 있는데 각 버젼의 디렉토리 안에는 두 종류(gzip, bzip2)로 압축된 커널 소스와 패치 파일이 있습니다. 원하는 버젼의 커널 소스를 가져 오시면 됩니다. 하지만, 공식 사이트는 전세계의 사용자들로 인해 트래픽이 심하기 때문에 우리나라의 미러 사이 트를 이용하는 것이 속도가 빠릅니다. 우리나라의 커널 소스 미러 사이트는 ftp://ftp.bora.net /pub/linux/kernel/ 과 ftp://ftp.nuri.net/pub/Linux/kernel/pub/linux/kernel/ 이 있습니다. 참고로, 현재 최신 버전은 안정 커널이 2.2.17pre-* 이고, 개발 커널은 2.4.0-test-pre* 입니다. ------------------------------------------------------------------------------------------ 자.. 이제부터는 딱딱하지 않게 옆에서 강의하듯 진행할 것입니다. 위의 글을 읽고 잠시 경직되 셨던 분들은 긴장을 푸시고 천천히 따라 오시면 되겠습니다. 그리고, 수업에는 항상 준비물이 필 요하듯이 여기서도 필요한 준비물이 있습니다. 이 준비물은 커널 컴파일을 하시기 전에 에러 메세지를 만나지않기 위해서는 반드시 필요한 준비 물이기 때문에 꼭 확인하시기 바랍니다. [ 필요한 패키지 ] 아래의 패키지 버젼은 2.4.0-test 커널을 사용하기 위한 버젼입니다. 커널 버젼 2.2-* 대의 패 키지도 별 문제 없이 될것입니다. 일단 다음의 패키지들이 설치 되어있는지 부터 확인을 해 보 시고, 컴파일 작업을 하시기 바랍니다. RedHat 기반 6.1이상의 배포판이라면 modutils만 업그레이드 하면 될 것입니다.(modutils를 업 하는데 glibc버전이 낮다면 glibc도 업해야 합니다. glibc는 로케일과 timezone, 여러 라이브 러리를 포함해서 의존성 문제에 많은 영향을 끼치므로 업그레이드 하는데 주의를 필요로 합니 다. rpm 버전이 낮다면 rpm도 업해야 합니다.) * glibc에 관한 자세한 내용은 박원규님의 홈페이지인 http://chem.skku.ac.kr/~wkpark/ 를 방 문 해 보시기 바랍니다. * ========================================================================= 패키지 명 버 전 확인 방법 ========================================================================= o Gnu C 2.7.2.3 # gcc --version o Gnu make 3.77 # make --version o binutils 2.9.1.0.22 # ld -v o util-linux 2.10o # kbdrate -v o modutils 2.3.13 # insmod -V o e2fsprogs 1.18 # /sbin/tune2fs --version o pcmcia-cs 3.1.19 # cardmgr -V o PPP 2.4.0 # pppd --version o isdn4k-utils 3.1beta7 # isdnctrl 2>&1|grep version ========================================================================= 만약 커널 2.4 버젼대의 컴파일 시 modutils 버전이 앞에서 명시한 버전보다 낮은 상태에서 모듈 컴파일을 한다면 에러가 납니다. 꼭 modutils를 업그레이드 해야 모듈 컴파일을 할 수 있습니다. modutils를 업하면 예전의 /etc/conf.modules가 /etc/modules.conf로 바뀌고, USB 모듈도 자동 로딩이 가능하며, 많은 예약어를 지원합니다. 다음의 ftp 사이트에서 구할 수 있습니다. ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.3/ ------------------------------------------------------------------------------------------ 지금부터의 모든 작업은 root 로 로그인 해서 해야 합니다. 참고로, 다음과 같은 명령으로 여러 분의 커널 버젼을 확인해 볼 수 있습니다. [root@queenrjh home]#uname -r <-- 단순히 커널 버젼만 표시 합니다. '-a' 라는 옵션으로 도 한번 해 보세요. rpm 으로 할 경우 커널 컴파일에 필요한 파일은 ftp://ftp.redhat.com 에서 받아오시면 됩니다. 일반 사용자인 경우 다 받을 필요는 없고, 다음의 두 개의 파일만 가져와서 설치하면 됩니다. [root@queenrjh home]#rpm -Uvh --nodeps kernel-header-(커널버젼).i386.rpm [root@queenrjh home]#rpm -Uvh --nodeps kernel-source-(커널버젼).i386.rpm rpm 파일은 실제로 여러가지가 있는데 왜 위와같이 꼭 두개의 파일만 받아와서 해야 하냐고 궁금 해 하시는 분은, 아래의 글을 읽어 보시면 왜 그런지에 대한 궁금증이 어느정도 풀리실 것입니다. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Q1) 커널 rpm 에는 소스, 헤더, BOOT 등등 여러가지가 있는데 이것들을 모두 받아 설치해서 커널 컴파일을 해야 하나요? A1) ==> 헤더, 소스 rpm 만 풀고 컴파일해도 됩니다. Q2) 그렇다면, 커널소스 이외의 것들(헤더,BOOT,doc 등)이 꼭 풀어야하는 것이 아니라면 왜 있는 것인지요? 그냥 옵션사항으로 사용자 개개인마다 알아서 풀고 싶으면 풀고 아니면 하지 말라 는 건가요? A2) ==> 처음에 리눅스를 설치할 때 커널 컴파일을 할 수 있을까요? 당연히 없겠죠? 그러니 처음 설치할 때는 이미 각각의 기능으로 컴파일 된 rpm 파일로 설치하는 수 밖에 없죠. 그 때 필요한 rpm 파일이 나머지 파일들이며, 특별한 이유가 없다면 나머지는 필요가 없습니다. Q3) 그럼, 커널 소스만 풀어서 컴파일하면, 나머지(헤더,BOOT,doc 등)도 저절로 생성이 되나요? A3) ==> 커널 컴파일해서 생성될 수 있는 것은 BOOT, smp이며, 나머지는 생성되지 않습니다. Q4) 그러면, 커널소스 이외의 것들(헤더,BOOT,doc 등)도 풀고 나서 컴파일을 해 주어야 하나요? A4) ==> doc 는 /usr/doc 밑에 들어가는 문서 파일이며, BOOT는 부팅할 수 있는 이미지와 모듈에 관련된 것이고, 헤더는 /usr/src/커널버전/include 디렉토리에 들어가는 헤더 파일들 입 니다. Q5) 커널 관련된 rpm 파일은 '소스, 커널 헤더, BOOT, doc, smp, pcmcia' 등이 있는데, 이 각각 의 파일이 어디에 쓰이는지 알려주세요. A5) ==> kernel-source... 커널 소스 rpm kernel-headers... 커널 헤더 rpm kernel-doc... 커널 문서 rpm kernel-BOOT... 부팅과 모듈 관련 rpm kernel-smp... 멀티 프로세서일 때 필요한 rpm kernel-pcmcia... 노트북 pcmcia에 필요한 rpm kernel-ibcs... Intel Binary Compatibility Specification 관련 rpm 위와 같은 커널 관련의 여러 rpm 파일들로 나뉘어 있는 것은 리눅스(정확히 레드햇)라는 것을 컴 퓨터에 처음 설치할 때는, 우리가 직접 커널 소스를 받아다 컴파일 할 때 처럼 필요한 것만을 알 아서 설치할 수 없기 때문에 각각의 기능을 컴파일해서 따로 나눠 놓은 것입니다. 그래서, 위의 여러 rpm 파일들은 설치 시에 기본적으로 필요한 파일들만 설치되고, 나머지 파일 들은 사용자가 필요할 때 사용되게 됩니다. 그리고, 설치 시에 리눅스에서 인식하는 하드웨어(사 운드카드, 랜카드 등)는 모듈로 띄워져서 인식하게 되구요. 인식하지 못하는 하드웨어나 세부적 인 부분은 수동으로 잡아야 합니다. rpm 파일의 커널은 모든것이 모듈로 포함되어 있기에 커널의 크기도 크고, 그만큼 메모리도 많이 잡아먹게 됩니다. 그래서, 커널 컴파일이라는 작업을 통해 커널을 최소화, 최적화하고, 또한 잡 히지 않은 하드웨어를 인식시켜야 합니다. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 이제 왜 커널에 관련된 rpm 파일이 커널 소스와 비교할 때 여러개이고, 그 각각의 파일이 어디에 사용되고 필요한지 아셨을 겁니다. 그럼 본격적으로 설치에 들어가겠습니다. rpm 파일을 -Uvh 옵션으로 설치할 경우에는 기존의 설치된 kernel-header 와 kernel-source 파일 들을 자동으로 지우고 새 버젼의 파일로 대체 하게 됩니다. 그렇기 때문에 이전 버젼의 커널소스 가 꼭 필요하신 분은 다른 이름으로 백업하시고, 새 버젼을 설치 하시기 바랍니다. CPU 가 2개 이상일 경우에는 kernel-smp-(커널버젼).i386.rpm 파일을 받아와야 하고, 노트북에서 리눅스를 실행 시키려면 전원 관리 기능을 제공하는 kernel-pcmcia-cs-(커널버젼).i386.rpm도 설 치해야 합니다. 소스로 설치 시에는 조금 다릅니다. 자세한 것은 이 글 맨 뒤에 설명 하겠습니다. 위와 같이 두개의 파일을 설치 하는데 뒤의 --nodeps 옵션은 header를 풀려면 source가... source를 풀려면 header가 있어야 한다고 설치를 거부 하기 때문에, 이 옵션을 주어 강제로 설치 합니다. 설치를 하면 /usr/src/linux-(커널버젼) 라는 디렉토리가 생깁니다. 그리고, 기존의 linux 링크를 지우고, 다시 linux 라는 이름으로 linux-(커널버젼) 를 새로 링크 시킵니다. 참고로 rpm 으로 설치 시에는 자동으로 되는 내용입니다. [root@queenrjh home]#cd /usr/src [root@queenrjh src]#rm -rf linux [root@queenrjh src]#ln -s linux-(커널버젼) linux 소스를 가져와서 컴파일 할 때는 이를 /usr/src 밑에 풀어줍니다. 압축을 풀면 위의 rpm 과는 반 대로 linux 라는 디렉토리에 압축이 풀립니다. 다음과 같이 합니다. [root@queenrjh src]#tar xzvf linux-(커널버젼).tar.gz (압축이 bzip2일 경우는 xlvf 옵션을 줍 니다.) [root@queenrjh src]#mv linux linux-(커널버젼) [root@queenrjh src]#ln -s linux-(커널버젼) linux 그런데, 여기서 왜 꼭 linux 라는 링크를 만들어서 쓰는지 궁금해 하시는 분이 계실 겁니다. 반드시 꼭 이렇게 해야 하는 것은 아니지만, /usr/src 디렉토리 아래에 여러 버젼의 리눅스 커널 소스를 두고 작업을 할 때 편하게 하기 위해 linux-(커널버젼) 이라는 이름으로 각 각 컴파일 시 에 그냥 쓰기 보다는 간단히 linux 라는 이름으로 링크를 시켜두고 사용하면 편하기 때문입니다. 이유는, 나중에 설명 드리겠지만 패치 작업할 때, 패치할 파일이 linux 라는 디렉토리의 안에서 찾도록 되어 있기 때문에 그런 이유도 있습니다. 반드시 그런 이유 때문은 아니지만, 패치할 때 나 다른 이유로 인해 그때 그때 이름을 바꾸는 것이 불편한 것만은 사실이기 때문이죠.. 다시 말씀 드리지만, 위와같이 이름을 링크 안 하셔도 상관없습니다. 그 대신 나중에 패치할 경 우가 생겼을 때 '패치가 안되고 에러만 나요..' 이런말 하셔도 절대 소용 없습니다. 절대루.. 그리고, 시스템의 심볼릭 링크가 새로운 커널 트리를 제대로 가리키고 있는지 확인해야 합니다. 보통 rpm 파일이 아닌 소스를 풀어서 하는 경우에 해주어야 하는 것이지만 레드햇 사용자의 경우 /usr/include 디렉토리에 아래처럼 링크를 해주지 않아도 기본적으로 잡혀 있습니다. 확인 차 한 번 'ls -l asm linux scsi' 로 확인 해 보시고 안 되어 있다면, 아래와 같이 해 주시면 됩니다. [root@queenrjh src]# cd /usr/include [root@queenrjh include]# rm -rf asm linux scsi [root@queenrjh include]# ln -s /usr/src/linux/include/asm-i386 asm [root@queenrjh include]# ln -s /usr/src/linux/include/linux linux [root@queenrjh include]# ln -s /usr/src/linux/include/scsi scsi 위에 것은 왜 링크를 해주어야 하는 거냐고 질문을 하는 분도 계시 겠군요.. /usr/include 디렉 토리는 표준 C 라이브러리 헤더 파일이 있는 중요한 디렉토리 입니다. 각 커널 소스에는 헤더 파 일이 딸려 오는데 컴파일 할 때 그 중에 asm linux scsi 디렉토리의 헤더 파일들을 불러 와야만 에러 없이 컴파일이 되는 경우가 있습니다. 시스템의 컴파일 환경 값으로 헤더 파일은 /usr/include 에서 불러 오기 때문에 커널 소스의 것 으로 링크를 해 주는 것입니다. 데비안 사용자들은 다음과 같이 두가지 명령을 해줄 경우 자동으로 kernel-*.deb 화일을 만들어 줍니다. [root@queenrjh src]#make xconfig [root@queenrjh src]#make-kpkg --revision=kor3 binary 위와같이 하면 현재 디렉토리에 아래와 같은 4개의 deb 화일이 생깁니다. 위의 옵션 중에 "--revision=kor3" 에서 "kor3" 는 여러분 임의대로 정하실 수 있습니다. 이 예 는 한글화의 "kor" 과 "3" 번째의 버젼이라는 의미로 붙였다는 것을 금방 눈치 채셨을 줄 압니다. kernel-doc-2.4.0-test9_kor3_all.deb kernel-headers-2.4.0-test9_kor3_i386.deb kernel-image-2.4.0-test9_kor3_i386.deb kernel-source-2.4.0-test9_kor3_all.deb 각각의 파일은 위에서 설명한 rpm 커널 파일의 내용과 동일 합니다. 단, rpm 파일에서는 없는 kernel-image-2.4.0-test9_kor3_i386.deb라는 파일은 커널 이미지 파일 입니다. 데비안에서의 설치는 dpkg 명령을 통해 rpm 에서와 같이 "-i" 옵션을 주어 설치합니다. dpkg -i kernel-image-2.4.0-test9_kor3_i386.deb 데비안의 대한 더 자세한 내용은 http://debianusers.org/ 와 http://www.debian-kr.org/ 의 홈 페이지를 통해 얻을실 수 있습니다. 물론 http://kldp.org 는 기본인 것은 다들 아시죠? ------------------------------------------------------------------------------------------ 여러분의 시스템에 필요한 드라이버나 새로운 기능 또는 수정된 내용의 다양한 패치를 할 경우가 있습니다. 패치를 해야 할 경우에는 /usr/src/linux/scripts 디렉토리에 여러 단계의 패치 작업 을 자동으로 실행하는 스크립트 patch-kernel 이 있습니다. /usr/src 아래에 가져다 놓은 커널 패치 파일들과 커널 소스의 버전과 비교하여 patch-kernel 은 순서에 따라 알아서 패치를 적용합 니다. [root@queenrjh src]#/usr/src/linux/scripts/patch-kernel 하지만, 리눅서라면 자동으로 되는 것도 좋지만 직접 패치도 해 보는 것이 많은 도움이 될 겁니 다. 우선 패치 파일도 압축 파일로 되어 있습니다. 압축을 풀어서 사용해도 되고 압축된 파일을 바로 패치 하는 법도 있습니다. 패치 파일을 /usr/src 에 복사 한 후 다음과 같이 하면 됩니다. 아래는 압축을 풀지 않고 바로 패치 할 경우 입니다. [root@queenrjh src]#gzip -cd newpatch.gzip | patch -p0 <-- 압축파일이 gzip 일 경우 [root@queenrjh src]#bzip2 -cd newpatch.bz2 | patch -p0 <-- 압축파일이 bzip2 일 경우 ** 여기서 잠깐! : 간혹 패치 파일이 확장자만 .gz 인 경우가 있습니다. gzip 으로 압축을 풀 려고 해도 안 되었던 분들이 계실 겁니다. 편집기로 파일안을 한번 들여다 보시면, 압축 파일이 아닌 패치 내용이 보일 겁니다. 이럴 경우는 그냥 확장자만 '.patch' 로 바꾸어서 아래의 내용을 참고로 패치 하세요. 이 것은 웹 서버가 브라우져의 요청에 의해 자료를 넘겨줄 때 압축을 풀어 서 주기 때문에 그렇습니다. 그 내용은 아파치 웹서버 설정에 있는 내용으로 알고 있습니다. 제 기억으론.. 이번에는 압축을 풀고 패치를 할 경우 입니다. 먼저 압축을 풀어야 겠지요? 압축을 푼 패치 파일 의 확장자는 .patch 나 .diff 끝나는게 대부분 입니다. 위와 마찬가지로 패치 파일이 /usr/src 디렉토리에 있을 경우입니다. [root@queenrjh src]#patch -p0 < newpatch.patch 여기서도 궁금증을 항상 갖고 계신분은 -p0 은 무얼까 하고 생각하시는 분이 계실 겁니다.. 쓸데 없는 것을 빼고, 항상 궁금증을 갖고 계시는 분은 좋은 자세 입니다. 그럼, -p0 라는 것은 무엇 인지 알려 드리겠습니다. 그리고, 위 에서 패치 파일을 /usr/src/ 에 복사하라고 했는데, 위에서 /usr/src/linux 디렉토리 를 안 만들면 후회 하네.. 어쩌네 해놓구선, 왜 이제와서 꼭 그곳에다 복사하라고 했는지도 궁금 하실 겁니다. 그럼, 패치에 대해서 잠깐 말씀 드리고 설명하겠습니다. 패치라는 것은 잘 아시다시피 어떤 곳을 고치거나 수정하기 위한 것으로 바뀌어질 부분만을 포함 하고있으며, 텍스트 파일 형식으로 되어있습니다. 패치가 적용될 파일은 보통 linux 라는 디렉토리 안에있는 특정 파일을 수정하는 내용으로 되어 있고, 패치하는 파일 안의 내용에는 linux 라는 경로 안의 특정 파일들을 수정하도록 하기 위한 내용이 들어있기 때문에 그렇습니다. 그래서, linux 디렉토리 안으로 직접 들어가지 않고 디렉토리 밖에서 패치할 경우에는, -p0 라고 옵션을 주어야 제대로 패치가 되는 것입니다. 그렇다면 -p1 은 무얼까요? 눈치가 빠른 분은 아셨겠지만 linux 디렉토리로 직접 들어가서 패치 할 경우에 사용 합니다. 사실 이렇게 주는 옵션은 패치를 만든 분의 설명 파일을 먼저 읽고 해 야 합니다. 보통 'README' 파일을 보거나 직접 .patch 파일 안을 직접들여다 보는 것도 좋습니다. 아직 무슨말인지 잘 모르시겠지요? 자.. 그렇다면, 다른말 필요없이 patch 파일의 내용을 한번 훑어 보죠.. ============================================================================= diff -urN v2.2.15/linux/arch/alpha/kernel/irq.c linux/arch/alpha/kernel/irq.c --- v2.2.15/linux/arch/alpha/kernel/irq.c Wed May 3 17:16:30 2000 +++ linux/arch/alpha/kernel/irq.c Wed Jun 7 14:26:42 2000 @@ -896,7 +896,13 @@ unsigned long __init init_IRQ(unsigned long memory) { wrent(entInt, 0); + - alpha_mv.init_irq(); + + /* If we had wanted SRM console printk echoing early, undo it now. */ + if (alpha_using_srm && srmcons_output) { + unregister_srm_console(); + } + return memory; } ============================================================================= 맨위의 diff 라는 것이 보이는데 이 것은 패치 파일을 diff 명령에다 -urN 옵션을 주어 만들었다 는 것을 나타 냅니다. diff 명령은 두 파일간의 차이점을 추출해 주는 정말 똑똑한 명령 입니다. 먼저 diff 명령을 설명하기전에 위에서 -p0, -p1 등이 이해가 안가셨던 분을위해 그것 먼저 설명 드리고나서 diff 명령을 알아 보겠습니다. 그럼, 아래를 보시죠.. diff -urN v2.2.15/linux/arch/alpha/kernel/irq.c linux/arch/alpha/kernel/irq.c ~~~~~~ 위의 diff 명령줄에 끝 부분에 물결표시로된 부분이 바로 그 해답입니다. linux 디렉토리 밑으로 해서 마지막에 irq.c 파일이 바로 패치 대상인 것입니다. irq.c 파일을 포함하는 제일 상위 디렉토리가 linux 디렉토리이기 때문에 그 linux 디렉토리 안으로 들어가서 패치를 하게되면 -p1 옵션을 주어야 하고, 들어가지 않고 밖에서 패치를 하면 -p0 옵션을 주게되 는 것입니다. 아시겠죠? 그럼, 이제 아시는 걸로 알고 diff 명령에 대해 설명 드리겠습니다. 음.. diff 명령의 사용법을 알려 드리기 전에 먼저 왜 그 것이 필요한지 설명을 좀 하겠습니다. 만일 'komputa' 라는 디렉토리 밑에 소스 파일이 있고, 그 디렉토리 안에 몇가지 내용을 어떤 이 유(버그나 기능 개선등..)로 수정한 후 tar 로 묶고, 압축을 해서 배포를 한다고 가정 해보죠.. 그럼, 그 이전에 배포한 소스를 받아서 사용 중인 사람은 새로 수정된 소스의 용량이 얼마 되지 않는다고 하면, 다시 새로 받는 것은 문제도 되지 않지만, 소스의 용량이 10 메가 이상이 된다면 모뎀 사용자들은 눈물을 흘려야 겠지요? 그래서, 소스 개발자나 버그 패치를 한 분은 바뀌어진 부분만 diff 명령으로 따로 추출해서 배포 하고, 사용자들은 위에 설명한 patch 명령으로 수정하면 되지요.. 정말 합리적이지 않나요? 여러분은 아직까지도 전 세계적으로 모뎀 사용자가 그것도 14,400bps 으로 사용하는 분이 아직도 많다는 것을 아시면 놀랄겁니다.. 그걸 보면, 우리나라는 인터넷 선진국임에 틀림 없습니다. 초 고속 인터넷을 쓰는 집이 하루 하루 늘어가는 것을 보면... 그럼, diff 명령을 한번 알아 보죠.. 위에서 예로 설명한 'komputa' 라는 디렉토리를 다시 한 번 예로 들어 보겠습니다. 단, 중요한 것은 수정 되기 전의 파일과 수정 한 파일을 따로 갖고 있어 야 한다는 것입니다. 그래야 아무리 똑똑한 diff 명령이라도 둘 중의 차이점을 비교해서 패치 파 일 이란걸 만들지 않겠습니까? 아래의 예에서 'komputa' 는 디렉토리이고, 그 안에 소스들이 있 다고 가정합니다. [root@queenrjh home]#cp -r komputa komputa.org <-- 먼저, 원본 소스 디렉토리를 다른 이름으 로 복사 합니다. 그리고, 새로 수정 되어질 디렉토리인 'komputa' 안의 소스들을 수정합니다. 수정을 다 하셨다면 다음과 같이 diff 명령을 내립니다. [root@queenrjh home]#diff -urN komputa.org komputa > newpatch.patch 여기서 한가지 주의 해야 할 것은 앞에서도 설명 드렸듯이 위의 명령을 komputa 디렉토리 밖으로 나와서 해야 합니다. 이 것은 위에서도 설명드린대로, 패치 시에 -p0 옵션을 주느냐.. 아니면, -p1 옵션을 주느냐의 민감한 차이로 바뀌기 때문 입니다. 이 것 또한 반드실 이럴 필요는 없습니다. 단 여러분이 만든 패치 파일을 다른 사용자들이 패치 시에 어떻게 패치하는 것이 더 좋은 것인지 한번 생각해 보고 하실 필요는 분명히 있는 것입니다. 위와 같이 하면 저 위의 예제로 보인 내용과 비슷한 내용의 패치 파일이 만들어 지는 것을 볼 수 있습니다. 이제 여러분도 패치 파일을 만들고, 패치도 적용할 수 있는 초보 마법사가 된 것 입니 다. 위의 옵션중 '-u' 는 'unified diff'으로 패치 파일의 내용을 일정 형식으로 생성하라는 것 이고, 'r' 옵션은 '--recursive' 으로 하부 디렉토리의 수정된 소스 파일도 적용하라는 것이며, 마지막의 'N' 옵션은 '--new-file'로서 원본의 내용과 달라진 내용을 뽑아내어 새로운 파일을 만 들어 내라는 것입니다. 이제 위에서 예를 든 패치 파일 안의 내용이 이해가 좀 가시나요? 물론, 아직 이 정도로는 양이 다 안 차실테니 좀 더 알려 드리겠습니다.. 아래를 한번 보죠.. ============================================================================= diff -urN v2.2.15/linux/arch/alpha/kernel/irq.c linux/arch/alpha/kernel/irq.c --- v2.2.15/linux/arch/alpha/kernel/irq.c Wed May 3 17:16:30 2000 +++ linux/arch/alpha/kernel/irq.c Wed Jun 7 14:26:42 2000 @@ -896,7 +896,13 @@ ============================================================================= 첫 번째 줄은 지금껏 설명한 내용이고, 그 다음 줄에 --- 로 시작되는 줄은 수정 되기 이전의 원 본 디렉토리 밑에 소스를 말하는 것입니다. 말할 것도 없이 다음 줄의 +++ 로 시작되는 것은 새 로 고쳐진 소스를 말하는 것이지요.. 그 줄 뒤의 것은 소스 파일의 생성 시간과 날짜 입니다. 간혹 날짜가 1970년대로 찍혀나오는 것이 있습니다. 이런것이 있어도 놀라실 필요는 전혀없습니 다. 기존의 파일내용을 전부 지워서 이름만 있고 크기도 0인 파일을 만들 경우거나, 완전히 새로 운 파일이 만들어 질때가 그런 경우입니다. 확실치는 않지만 제 경우에는 그렇더군요.. 뭐.. 중요한 내용은 아니므로 넘어가죠.. (날짜가 중요하게 여겨지는 분들은 신경 쓰시고요..) 그럼 다음의 것은 또 무얼 가리키는 것 일까요?.. 마치 무슨 암호문 같기도 한데.. '@@' 문자로 시작되는 줄은 그 다음 줄 부터 과연 무엇이 수정 되는지를 알려주는 것입니다. '@@' 문자 뒤의 숫자에서 '-'표시로 시작되는 숫자는 원본 소스의 896 째 라인부터 그 아래 7 째 줄까지 내용이 빠진다는 것을 의미하고, '+' 로 시작하는 것은 수정되는 소스 파일의 896 째 줄 부터 13 줄의 내용이 첨가 된다는 것을 나타 냅니다. 아래를 다시 잘 보면 이제 어느 정도 이해 가 될 것입니다. 그리고, '@@' 문자로 시작하는 그 다음 줄 부터의 내용에서 앞의 '-' 표시와 '+' 표시의 갯수가 각 각 몇 개 인지를 세어 보세요. 그리고, 앞에 아무 표시도 없는 줄과 '-' 표시, 빈 공백 라인 을 포함해서 총 7 줄인 것을 알수 있습니다. 그 숫자가 -896,7 와 맞아 떨어 지는 것을 알 수 있 습니다. 또한, 앞에 아무 표시도 없는 줄과 '+' 표시, 빈 공백 줄을 포함 하면, +896,13 도 역시 그 수를 의미 하는 것을 알 수 있습니다. ============================================================================= @@ -896,7 +896,13 @@ unsigned long __init init_IRQ(unsigned long memory) { wrent(entInt, 0); + - alpha_mv.init_irq(); + + /* If we had wanted SRM console printk echoing early, undo it now. */ + if (alpha_using_srm && srmcons_output) { + unregister_srm_console(); + } + return memory; } ============================================================================= 더 간단히 보는 방법도 있습니다. 정확히 맞아 떨어지는 것은 아니지만, 빨리 대강 훑어보는데는 도움이 됩니다. '@@'로 시작하는 줄의 '-' 표시 다음 두개의 숫자중 뒤의 숫자에서 6을 뺀 값이 결국 빠지는 값이 됩니다. 이유는 '@@'로 시작하는 줄 아래를 잘 보시면, '-' 나 '+' 문자가 나 오기 전까지 공백을 포함한 줄이 항상 3줄이고, 다시 '@@'로 시작하는 줄이 나오기 전까지의 줄 도 공백을 포함해서 3줄로 끝나게 됩니다. 무슨 얘기를 하는지 모르시는 분을 위해 예를 들어 설 명 하겠습니다. 위의 '@@ -896,7 +896,13 @@' 줄에서 896번째의 줄에서 7줄 만큼의 내용을 뺀다는 내용은 아실겁 니다. 7이라는 숫자에서 6을 빼면 '1'... 다시 설명하면, 896번째의 줄에서 결국 1줄만이 빠지 는 겁니다. 위를 다시 보십시요.. 그렇죠? '-' 라는 표시가 한번 밖에 없지요? 이제 아시겠 습니까? 그럼, 이번에는 뒤의 숫자를 볼까요? '+896,13 @@' 의 내용도 다를바 없습니다. 두번째 숫자인 13에서 6을 빼면 7이 됩니다. 다시한번 위의 내용에서 '+' 표시를 세어 보세요.. 7개 맞지요? 하지만, 이렇게 보는 것이 절대적은 아닙니다. 단, 빨리보기 위해 이렇게 보시면 편하다는 것을 알려 드린것 뿐입니다. 이유는 패치할 파일의 내용이 처음부터 빠진다거나 추가되는 내용이라면 그렇지 않으리라는 것은 짐작이 가실 겁니다. 이해가 안되시는 분을 위해 예를 또 한번 들지요. ============================================================================= @@ -896,3 +896,6 @@ + unsigned long __init init_IRQ(unsigned long memory) + { + wrent(entInt, 0); alpha_mv.init_irq(); ============================================================================= ============================================================================= @@ -896,6 +896,3 @@ if (alpha_using_srm && srmcons_output) { unregister_srm_console(); } - - return memory; - } ============================================================================= 첫번째의 예에서 제가 말씀드린대로 한다면, 3에서 6을 뺄 수가 없지요? 첫번째 예는 패치할 파 일의 맨 처음부터 추가되는 예이고, 두번째 예는 반대로 패치할 파일의 맨 마지막의 내용이 빠지 는 내용을 예로 든것입니다. 이제는 이해가 가십니까? 아.. 여기서 한가지 중요한 사항이 있는데, 일부 패치하시는 분들이 패치 파일 안의 내용을 직접 수정할 때 눈으로 봐서는 아무 이상이 없는데도 패치가 안되는 경우가 있을 것입니다. 이런 경우는 극히 드문 경우지만 원인은 사용자가 직접 수정하였을 때 생기는데, 여러분이 수정 하신 부분의 앞 줄이 "+", "-", "@@" 표시와 diff 명령으로 시작하는 부분은 빼고, 전부 한 칸의 공백을 띄어 주어야 합니다. 원본에서 빼거나 추가 할 부분 앞에 "-" 표시나 "+" 표시가 들어 가기 때문에 각 줄의 앞에는 "+", "-", "@@" 표시와 diff 명령 외에는 다른 문자나 기호가 오면 패치시 항상 에러가 나게 됩니다. 그러므로, 괜히 패치 파일의 내용을 함부로 건드리시면 안됩니다. 그렇지 않으면 패치시 고달프 게 될겁니다. 시험삼아 한번 해 보세요.. *^^* 마법사가 되기위한 길은 거져 먹을 만큼 쉬운 것이 아닙니다. 이 옵션을 직접 그 흔한 'hello' C 소스 파일을 원본 파일과 수정 파일을 하나씩 만들어서 직접 테스트 해 보세요. 옵션을 주고 안 준 차이가 과연 무엇인지를.. 좋은 경험이 될 것입니다. 지금 바로 해 보세요.. ^^; 옵션 얘기가 나와서 말인데.. 참고로, 위의 예를 다시 들어 간혹 -urN 과 -u -r -N 이렇게 따로 내릴 경우를 보게 되는데, 리눅스에서는 특별하게 달리 만들어진 프로그램이 아닌 경우를 빼고 는 같은 것입니다. 또한, 옵션 중에 앞에 '-' 표시를 두개 붙인 '--force' 와 같은 옵션은 GNU 의 산물로써 GNU 에서 제작된 프로그램들은 알파벳 1개로 된 옵션 이외에 사람이 이해 하기 쉬운 단어 형식으로 된 옵션을 지원하므로, 단어 형식의 옵션 앞에는 '-' 표시가 하나 더 붙습니다. 예를 들어, 도움말을 보기 위한 옵션으로 '-h' 와 '--help' 둘 다 지원하는 것이 그 예 입니다. 그럼, 왜 이렇게 커널과 별 상관 없는 듯한 얘기를 하는지는 제 맘을 헤아릴 수 있는 분이나, 한 번 이라도 패치를 해 보려고 했다가 패치는 안되고 밑에 얘기할 .rej (rejected - '거부된' 라는 뜻임) 파일만 잔뜩 쌓일 때의 실망감을 아는 분은 위의 패치 내용을 아는 것이 얼마나 도움이 될 것 인지는 두 말하면 잔소리라는 것을 잘 아실 겁니다. 자.. (한숨 한번 쉬고.. 힘드네요..) 커널 소스도 마찬 가지 입니다. 만일 linux-2.2.14 소스를 사용하시다가 linux-2.2.17pre-* 의 최신 버젼을 사용하고 싶을 때, 인터넷 속도가 빠르신 분은 거의 20 메가에 가까운 소스를 한번에 다 받으셔도 되지만, 그렇지 않은 분들은 여전히 눈물만.. 그래서, 패치 파일을 받아 와야 하는데 여기서 중요한 사실은 linux-2.2.14 과 linux-2.2.17pre 사이의 중간 버젼의 패치를 모두 받아와야 한다는 것입니다. 즉, linux-2.2.15, linux-2.2.16 버 젼의 패치가 필요 하다는 것이지요.. 하지만, linux-2.2.14 에서 linux-2.4.0-test* 버젼을 사 용하기 위해 그 중간 단계의 패치 버젼을 다 가져와서 사용 하려는 분이 있다면.. 없겠죠? ^^; 어쨋든, 우여곡절을 다 겪어서 패치가 성공했다면 패치 대상이 된 파일의 원본은 이름끝에 .orig 라는 이름이 붙어 백업 됩니다. 패치 과정에서 문제가 생겨 실패 했다면 실패한 파일 이름 뒤에 위에서 잠시 설명한 그 문제의 '.rej' 파일이 만들어 집니다. .rej 파일을 잘 살펴 보시고, 다 시 패치 작업을 수행 합니다. 소스가 복잡한 경우에는 .rej 라는 파일이 각 디렉토리 마다 생길 수 있는데, 그 것을 일일히 찾 는 다는 것은 시간 낭비이므로, 아래와 같이 find 명령으로 찾아 보시면 됩니다. [root@queenrjh src]#cd linux [root@queenrjh linux]#find . -name "*.rej" 위와 같이 해서 '*.rej' 파일을 찾을 수 없다면 패치가 성공한 것이므로, 다음과 같은 명령으로 원본 파일인 '*.orig' 파일을 삭제합니다. [root@queenrjh home]#find /usr/src/linux/ -name "*.orig" -exec rm -f {} ; 역시 또다른 암호문과 같은 명령이 시작 되는군요.. 리눅스나 유닉스는 이런 명령어와 옵션의 천 국입니다. 열심히 공부해서 그 암호문들을 다 박살내 봅시다. 마법사들을 부러워만 하지말고.. 위의 find 명령중 파일명을 인용 부호인 (") 으로 묶은 것은 별표 '*' 를 우리가 흔히 알고 있듯 이 파일명 전체를 의미 하는 메타 문자 이므로, '.rej' 나 '.orig' 라는 확장자를 포함한 파일을 쉘이 해석하기 위해서 이고, -exec 옵션에서부터 라인의 끝을 나타내는 세미 콜론 ';' 까지 중간 에 있는 명령을 수행 하라는 것인데, 중간에 '{}' 라는 부분은 찾은 파일의 이름으로 대체 되기 위해 쓰는 것이고, 세미콜론 앞의 백 슬래시인 '' 표시는 뒤의 명령의 끝을 알리는 세미 콜론을 쉘이 먼저 해석하지 않기 위해 쓰이는 것입니다. 위와같은 내용을 아시고 다음부터 find 명령을 쓰신다면, 확실히 예전에 모르고 이상한 문자를 단순히 외워서 할 때와는 달리 기억이 잘 나실 겁니다. 그렇죠? 단순히 외우는 건 오래가지 못 합니다.. 원리를 알자~~!! 그럼 (") 인 겹 따옴표로 묶은 것은 왜 일까요? 우리가 일반적으로 쓰는 홑 따옴표도 있는데.. 우선, 홑 따옴표든.. 겹 따옴표든 이것을 '인용부호' (quote) 라고 부릅니다. 분명히 서로 다른 기능이 있기에 구분해서 쓸 것이라는 것은 벌써 짐작 하셨을 겁니다. 그럼, 먼저 인용 부호의 필 요성에 대해 살펴 봅시다.. [root@queenrjh home]#echo I love you <-- love 다음에 공백을 2칸 이상 띄웠다면.. 위와 같이 명령을 내리면 love 와 you 사이의 공백은 1칸 이상은 무시 됩니다. 그래서 출력은 다 음과 같이 'I love you' 라고 출력되게 됩니다. 여기서 '아 하~ ' 하고 눈치를 채셨을 겁니다. 맞습니다. 공백을 포함한 문자열을 묶어서 사용할 때는 인용 부호를 쓰게 됩니다. 그렇다면, 이 제 각 인용 부호의 차이점을 알아 보겠습니다. [root@queenrjh home]#echo "I love you" [root@queenrjh home]#echo 'I love you' 위의 두 차이점은 무엇일까요? 사실 위와 같이 단순 문자열을 묶어서 사용할 때의 차이점은 없습 니다. 그러나, 다음의 예를 보죠.. [root@queenrjh home]#echo "I love you $SHELL" [root@queenrjh home]#echo 'I love you $SHELL' 자.. 이제는 서로의 차이가 확연히 드러나는 순간입니다. 지금 리눅스 박스 앞에 앉아 계시다면 위의 예를 한 번 해 보세요.. 이제 좀 아시겠지요? 겹 따옴표 (") 는 메타 문자를 해석 하면서 본인의 임무인 문자 열을 묶어서 나타 냅니다. 그러나, 홑 따옴표 (') 는 메타 문자를 무시하고 단순한 문자 열 로만 취급하게 됩니다. 이 차이는 아주 중요합니다. 별 생각없이 인용 부호를 사 용 하셨다면, 지금 부터 확실히 인지 하시고 쓰시기 바랍니다. '$' 표시는 변수의 기능으로 쓰기 위해 변수로 쓰일 문자 앞에 붙여 줌으로써, 그 문자가 변수라 는 것을 쉘에게 알려주는 메타 문자 입니다. 변수로 쓰이는 문자는 일반적으로 위에서 'SHELL' 처럼 대문자를 사용 합니다. 물론 소문자를 사용하기도 합니다만, 대문자를 사용하는 이유는 단 지 관례라고 생각 하시면 됩니다. 눈에도 확연히 잘 띄구요.. 하지만, 이것도 반드시라고는 할 수 없습니다. 어떤 분들은 환경변수와 구분하기 위해서 꼭 소문 자로 써야 된다고 하시는 분이 있으므로.. 결론은 여러분 맘... 참고로, 위 에서 잠깐 설명했던 '' 나 '*' 또는, '$' 와 같은 문자를 '메타 문자' 라고 부르며, 각각 특수한 용도로 사용을 하게 됩니다. 위 의 세가지 말고도 많은 메타 문자가 있으며, 이 메 타 문자를 명령어가 해석하지 않고, 쉘이 먼저 해석하여 명령에게 그 값을 돌려주게 됩니다. 명령어가 해석하고 싶어도 할 수 없습니다. 왜냐하면, 메타 문자는 쉘 만이 해석 할 수 있는 특 권을 갖고 있으니까요. 꼭 기억 하세요. 메타 문자를 함부로 처리하면 쉘 한테 혼납니다.. ^^; 특히, 백 슬래시인 '' 는 메타 문자를 해석 시키지 않는 역할을 합니다. 자기도 메타 문자이면 서 메타 문자를 제어하는 왕초 라고나 할까요? 단, 백 슬래시 다음에 오는 메타 문자 한개만 그 기능을 없앱니다. 일정 범위 안의 메타 문자의 효력을 없애기 위해서는, 위에서 설명한 홑 따옴 표 (') 만이 그 일을 할 수 있지요. 그럼, 다음의 예를 조금 들어 보겠습니다.. [root@queenrjh home]#echo SHELL <-- echo 명령을 예와 같이 내리면 그냥 'SHELL' 이라고만 출력 됩니다. [root@queenrjh home]#echo $SHELL <-- 이번에는 사용하고 있는 쉘의 경로와 이름이 출력되는 것을 볼 수 있습니다. [root@queenrjh home]#echo $SHELL <-- 여기서는 '$SHELL' 라는 출력을 보여줍니다. '$'의 기 능을 '' 표시가 자신의 능력으로 막았군요. 명령 뒤에 메타 문자가 나오면 먼저 쉘이 해석하고, 그 값을 명령에게 돌려 주기 때문에 echo 명 령은 '$SHELL' 이라는 메타 문자 다음의 것은 구경도 못하게 되고, '/bin/bash' 라는 값만 출력 하게 됩니다. 그럼, 아래와 같은 경우는 어떻게 될까요? 궁금 하시죠? 한번 해 보시면 피가되고, 살이.. ^^; [root@queenrjh home]#echo $SHELL $PATH $HOME $USER [root@queenrjh home]#echo $SHELL $PATH $HOME $USER [root@queenrjh home]#echo '$SHELL $PATH $HOME $USER' 그리고, 변수는 '환경 변수' 와 '지역 변수(사용자 정의 변수)' 로 나뉘어 집니다. 자신이 정의 한 변수를 쉘에서 계속 사용하려고 하신다면, 아래와 같이 쉘에서 정의를 하시고 사용하시면 됩 니다. [root@queenrjh home]#export STAR=Blizzard <-- export 명령으로 지역 변수를 환경 변수화 시킵니다. [root@queenrjh home]#echo $STAR Blizzard 참고로 하나 더, 간혹 홑 따옴표는 홑 따옴표인데 키보드의 숫자 "1" 왼쪽의 (`) 표시를 보신 적 이 있으실 겁니다. 이것은 주로 쉘 스크립트 안에서 쓰이는데, 쓰이는 용도는 변수의 값에 리눅 스 명령의 내용이 들어갈 때 쓰입니다. 다시 예를 들어 볼까요? command=`echo $opt` 위의 예는 echo 명령을 통해 opt 변수의 내용을 출력한 값을 command 변수 안에 넣으라는 것입니 다. 이 때 (`) 표시인 홑 따옴표 대신 스트링 문자를 둘러싸는 겹 따옴표를 쓰게 되면, command 의 변수 안에는 단순히 "echo" 라는 문자열과 opt의 변수 내용이 같이 스트링 값으로 들어갑니다. 음.. 얘기가 완전히 다른 길로 빠져 버렸군요. 그래도, 모르는 것 보다는, 아는 것이 힘이니까.. 내친 김에 아는 분도 계시겠지만, 모르는 분들을 위해서 아래의 팁까지... ------------------------------------------------------------------------------------------ [팁!] 다음으로 진행 하기에 앞서 커널 컴파일을 할 때 이에 대한 프로세서를 가장 우선순위에 두고 싶 다면 make 명령 앞에 nice -20 또는 nice --20 을 적어 줍니다. 예를 들어 아래와 같이 할 수 있습니다. nice -20 make mrproper menuconfig dep clean bzImage nice -20 make modules modules_install nice명령어는 어떤 프로그램을 컴파일을 하던지 ./configure 나 make명령 앞에 붙여 주면 됩니다. 그리고, 2개 이상의 cpu 를 가지고 있을 경우 컴파일을 각 cpu 에 동시에 할당 해 주면, 컴파일 을 병렬로 처리 하기 때문에 속도가 빨라 집니다. 그렇게 하기 위해서는 '-j (숫자)' 옵션을 사 용 합니다. -j 옵션 다음의 숫자를 지정할 공식은 다음과 같습니다. -j (숫자) = ( 램 용량 / 8 ) + 1 예로, 램이 128 메가인 경우에는 -j 17 이 됩니다. SMP 시스템에서 더 많은 이득을 볼 수 있지만, 단일 프로세서 시스템에서도 -j 는 적절한 성능을 보여 줍니다. 실제 사용 예는 아래와 같습니다. make -j5 mrproper menuconfig .... make -j5 modules modules_install .... ------------------------------------------------------------------------------------------ 자.. 이제부터 본격적인 커널 컴파일에 들어 갑니다... [root@queenrjh include]#cd /usr/src/linux [root@queenrjh linux]#make mrproper make mrproper 명령을 내리는 이유는 이전 커널을 컴파일할 때 만들어진 오브젝트 파일과의 의존 성 설정내용, 컴파일 환경 설정값, 버전 정보 등 새로 시작하는 컴파일에 영향을 주는 이전 정보 를 소스 커널의 원래 설정으로 초기화 해 주는 명령이므로 새로 커널 소스를 설치했을 경우는 이 명령이 필요 없습니다. 그러나, 새로 받아온 소스로 컴파일 하는 것이 아니라, 기존의 커널 소스를 계속 사용 할 것이고, 그 소스로 컴파일을 한 번 이라도 하였으며, 그 소스의 설정 값들을 잃고 싶지 않은 분이라면 이 명령을 내리지 마십시요. 지금부터는 본격적인 커널 설정에 들어가는 내용입니다. 콘솔에서 실행 하시던지, 아니면 X 터미 널에서 다음 명령을 내리시던지 간에 반드시 /usr/src/linux 디렉토리로 이동하시고 명령을 내리 십시요. [root@queenrjh linux]#make xconfig 커널 설정에는 xconfig, menuconfig, config 가 있는데 X-윈도우가 된다면 xconfig로 설정하는게 편합니다. make xconfig를 수행하기 위해서는 X-윈도우와 TcL/Tk 인터프리터/툴킷 라이브러리가 반드시 필요합니다. 그리고, 설정이 끝나면 반드시 주 화면의 'Store Configurationto FiLe' 항 목에서 설정 내용을 파일로 저장합니다. 참고로, 커널 옵션 설정후 설정내용은 /usr/src/linux에 '.config' 라는 이름으로 저장됩니다. make menuconfig 는 ncurses(new-curses)라는 라이브러리가 설치되어 있어야 합니다. ncurses 는 화면 입/출력에 쓰이는 라이브러리 입니다. ncurses 가 설치되지 않았다면 실행되지 않는 풀그림 들이 많으므로 반드시 설치합니다. 위와 마찬가지로 설정을 마쳤다면 반드시 저장하고 나옵니다. config 는 텍스트로 된 방식으로 요즘 거의 쓰이지 않고 있습니다. 심심 하다면 한번 해보시길.. 어떤 식으로 할지를 선택 하셨다면 원하시는 명령으로 커널 설정을 하시면 됩니다. 중요한 것은 자신의 시스템에서 사용하고 있는 하드웨어를 잘 알고 있어야 한다는 겁니다. 세상에 거져 되는 것은 없나 봅니다.. ^^; 음.. 그리고, 지금부터는 커널 설정 내용중 가장 기본이 되는 부분만을 간단히 소개해 드리겠습 니다. 초기의 문서에는 아예 넣지 않았는데, http://kldp.org 의 권순선님께서 이 내용까지 넣으 면 완벽(?)하다는 유혹에... 아래의 내용은 http://kernel.pe.kr 의 정원영님 글에서 그대로 인 용했습니다. [ 기본적인 커널 옵션 설정 ] 일반적인 데스크탑 PC사양(1 CPU, No SCSI)에서 필요로 하는 커널 옵션들을 설명하며, 그다지 필 요성이 없는 옵션들은 제외시켰다. Code maturity level options ---> [*] Prompt for development and/or incomplete code/drivers - 개발 수준의 옵션들도 선택 가능 하게 해준다. Loadable module support ---> [*] Enable loadable module support - 모듈을 사용할수 있게 해줌. [*] Kernel module loader - 커널이 알아서 모듈을 올려준다. Processor type and features ---> (Pentium-Pro/Celeron/Pentium-II) Processor family (X) Pentium-Pro/Celeron/Pentium-II - 테스트 PC가 Pentium II이므로 ... 시스템에 맞는걸 선택 한다. [*] MTRR (Memory Type Range Register) support - 프로세서가 메모리 영역 접근을 제어할 수 있 음. 그래픽의 쓰기 속도 향상. General setup ---> [*] Networking support - 네트워킹 지원. [*] PCI support - PCI 지원. (Any) PCI access mode - 커널이 직접 액세스 시도. [*] System V IPC - System V IPC를 지원하게 함, Shared Memory도 여기서 지원한다. [*] BSD Process Accounting - 프로세스 정보를 파일에 저장. [*] Sysctl support - 특정 커널의 파라미터와 변수들을 동적으로 변경시킬수 있도록 함. (ELF) Kernel core (/proc/kcore) format - ELF core 포맷. <*> Kernel support for a.out binaries - a.out 바이너리 지원. <*> Kernel support for ELF binaries - ELF 바이너리 지원. Plug and Play configuration ---> <*> Plug and Play support - Plug and Play 지원. Block devices ---> <*> Normal PC floppy disk support - 플로피 드라이버 장치 지원. Loopback device support - 한 파일을 하나의 파일 시스템처럼 인식 시킴. Networking options ---> <*> Packet socket - 네트웍 디바이스와의 직접통신을 하게 해준다. <*> Packet socket: mmapped IO - 더 빠른 통신을 할 수있게 한다. <*> Unix domain sockets [*] TCP/IP networking - TCP/IP 네트워킹 지원. [*] IP: TCP syncookie support (disabled per default) - 서비스 거부 공격을 받을때 대처해 줌. ATA/IDE/MFM/RLL support ---> <*> ATA/IDE/MFM/RLL support IDE, ATA and ATAPI Block devices ---> <*> Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support - IDE를 사용할수 있도록 해준다. <*> Include IDE/ATA-2 DISK support - 하드디스크 사용가능하게 함. <*> Include IDE/ATAPI CDROM support - CD-ROM 사용가능하게 함. Include IDE/ATAPI FLOPPY support - ZIP 드라이브등을 사용가능하게 함. --- IDE chipset support/bugfixes <*> Generic PCI IDE chipset support - PCI 방식의 IDE 지원. <*> Sharing PCI IDE interrupts support - IRQ 공유 지원. <*> Generic PCI bus-master DMA support - DMA 지원. <*> Use PCI DMA by default when available - VIA VP2 칩셋을 사용한다면 절대 선택하지 말것. <*> HPT366 chipset support - Ultra DMA 66 지원. Network device support ---> [*] Network device support Ethernet (10 or 100Mbit) ---> [*] Ethernet (10 or 100Mbit) - 자신의 시스템에 맞는걸 선택 (RealTek 8139등을 쓴다면, [*]EISA, VLB, PCI and on board controllers를 선택하면 하부 목록이 나온다.) Character devices ---> [*] Virtual terminal - 가상 터미널 지원. [*] Support for console on virtual terminal - 가상터미널을 시스템 콘솔로 쓸수있게 해준다. [*] Unix98 PTY support - Unix98 가상터미널 지원. [*] (256) Maximum number of Unix98 PTYs in use (0-2048) Unix98 PTY 개수의 최대값. Mice ---> <*> Mouse Support (not serial and bus mice) [*] PS/2 mouse (aka "auxiliary device") support - PS/2 마우스 지원. /dev/agpgart (AGP Support) - AGP 지원. (하부메뉴중 자신의 보드에 맞는거 선택) File systems ---> <*> Kernel automounter support - 원격 파일 시스템을 자동으로 마운트 해준다.(NFS등을 사용할 때) N을선택해도 상관없다. DOS FAT fs support - FAT 기반의 파일 시스템 지원. MSDOS fs support - MSDOS 파티션 마운트 지원. VFAT (Windows-95) fs support - 윈도즈 파티션 지원. ISO 9660 CDROM file system support - CD-ROM 파일 시스템 지원. [*] Microsoft Joliet CDROM extensions - Joliet CDROM을 읽을 수 있게 한다. [*] /proc file system support - 프로세스를 위한 가상 파일 시스템. [*] /dev/pts file system for Unix98 PTYs - 위에서 [*] Unix98 PTY support를 선택했다면 선택 해야 한다. <*> Second extended fs support - 현재 리눅스 파일 시스템. Network File Systems ---> NFS file system support - 네트웍 파일 시스템 지원. SMB file system support (to mount Windows shares etc.) - 윈도즈의 네트웍 기능들을 공유 할 수 있게 해준다. Native Language Support ---> Default NLS Option: "cp949" - 디폴트로 한글이 선택되도록 한다. <*> Codepage 437 (United States, Canada) <*> Codepage 949 (UnifiedHangul) - 윈도 파티션을 마운트 했을 때 한글을 볼 수 있도록 해준다. <*> NLS ISO 8859-1 (Latin 1; Western European Languages) Console drivers ---> [*] VGA text console - VGA 표준 디스플레이를 통해 텍스트 모드에서 사용 가능하게 한다. Sound ---> 시스템에 맞는걸 선택한다. Kernel hacking ---> [*] Magic SysRq key - 시스템이 다운되더라도 제어할 수 있도록 해준다. 위의 옵션에서 설명했듯이, 윈도우의 파티션을 마운트 했을 때 한글 이름으로 된 파일이나 디렉 토리가 "?????" 이런식으로 보이는 문제를 해결하기 위해서는 커널에 한글 패치를 해야 하는데, 커널 2.2.16 부터는 한글을 보기 위한 패치를 하지 않아도 되게끔 커널 소스 디렉토리인 linux/fs/nls 에 nls_cp949.c 라는 파일로 한글을 지원합니다. 이 것을 모르시는 분은 아직도 게시판에 " '???' 와 같이 한글이 보이지 않는데 어떻게 하나요?" 라는 글이 거의 하루 걸러 올라오는 걸 볼 수있죠.. 다시 말씀드리지만, 한글 사용을 위한 커널 옵션 설정은 내용 중 Filesystems 에서 아래의 두 가지 항목을 선택 하세요. <*> DOS FAT fs support <*> VFAT(Windows-95) fs support 그리고, 밑으로 조금 내려가다 보시면, Native Language Support 라는 설정 내용이 있습니다. 그 안의 내용 중 Default NLS Option: "cp949" 로 바꿔 주시고, 아래의 항목을 선택 하시면 됩니다. <*> Codepage 949 (UnifiedHangul) 커널 설정 내용은 아주 많지만, 위의 내용 정도로 간단히 소개하고 끝내겠습니다. 그 대신 커널 옵션 한글화 프로젝트 팀(http://kernel.pe.kr)의 홈페이지에 있는 것을 참고 하세요. 자세한 건 http://kernel.pe.kr/data/doc/kernel_option.html에서 커널 설정에 관련된 좋은 자료를 얻을 수 있습니다. 그 이외의 다양한 글과 자료는 여러분도 다 아시는 http://kldp.org 를 이용하십시요. 의외로 많은 분들이 다른 곳에서 헤메고 계시더군요.. 그리고, 참고로 말씀 드리자면 자신의 시스템에 가장 필요한 것 외에는 선택하지 마시고, 필요한 디바이스는 모듈로 하는 것이 가장 좋은 방법입니다. ------------------------------------------------------------------------------------------ 위에서 커널 컴파일 설정을 다 하셨으면 꼭 저장을 하고 나온 후, 아래와 같은 명령을 내립니다. [root@queenrjh linux]#make dep; make clean [root@queenrjh linux]#make bzImage make dep는 설정을 다 한 후에 커널 이미지를 생성하기에 앞서 필요한 라이브러리나 헤더 파일등 이 시스템에 제대로 있는지의 의존성을 확인하기 위한 것이고, make clean 은 기존의 소스로 컴 파일을 한 번 이라도 한 경우에 생겼을 오브젝트 파일이나 임시 파일, 커널 이미지등의 잔여물을 없애기 위한 것으로 소스 파일이나 rpm 파일을 새로 가져와서 처음 할 경우에는 안 해도 별 상관 없지만, 습관처럼 그냥 외워서 하시는 것도 나쁘지 않습니다. 그래야 나중에 괴로움을 겪지 않습 니다. 앞으로 모 화장품 CF 에서 처럼 '딥 클린'이라고 외워 보세요. 잊어먹지 않을 겁니다. ^^; 위와 같이 하면 커널 이미지를 만듭니다. zImage 도 있지만 커널 이미지가 클경우 마지막에 에러 가 나므로 아예 처음부터 bzImage 명령으로 작업하는 것이 나을 겁니다. make bzImage 명령시 출력되는 장황한 메세지를 안 보이게 하려면 -s 옵션을 주어서 다음과 같이 하면 됩니다. 나중에 경과 메세지나 잘못 되었을 경우의 에러 메세지만 보여줄 것입니다. make -s zImage 또는 make -s bzImage 간혹 어떤 분은 zImage 와 bzImage 명령에서 Image 스펠링에서 앞의 I(대문자 i) 를 소문자로 명 령을 내리시고는, 명령이 듣지 않는다고 하시는 분이 계십니다.. [반드시!!] 대문자로 하세요.. make bzImage 명령 대신 make bzlilo 명령이 있는데 이것은 기존의 커널 이미지와 System.map 를 백업하고, 새로운 커널 이미지인 vmlinuz-(커널버젼) 이미지를 만든 다음, 다시 vmlinuz 로 심볼 릭 링크하고, System.map 도 마찬가지로 System.map-(커널버젼) 을 System.map 로 심볼릭 링크하 며, lilo 까지 알아서 하게 됩니다. 단, 커널 이미지가 설치되는 디렉토리가 '/boot' 디렉토리가 아닌 '/' 루트에 설치 됩니다. rpm 사용자는 기본으로 설정되어 있기 때문에 해당 사항 없습니다. 만일 /boot 디렉토리에 자동으로 설치되게 하려면, /usr/src/linux/Makefile 파일에서 다음과 같 이 맨 앞의 주석처리인 '#' 부분을 제거하면 됩니다. # # INSTALL_PATH specifies where to place the updated kernel and system map # images. Uncomment if you want to place them anywhere other than root. # #export INSTALL_PATH=/boot <-- 맨 앞의 '#' 부분을 제거한다. 즉, make bzlilo 는 make bzImage;make install;lilo 를 동시에 하는 명령이므로 편할지는 모르 지만 제대로 잘 안되는 경우도 있고, 자기의 입맛에 맞게끔 하기 위해서는 아무래도 수동으로 작 업하는 것이 제일 확실합니다. make zlilo 도 있는데, 이것은 미루어 짐작할 수 있는 것과 같이 make zImage;make install;lilo 를 한 번에 해주는 명령입니다. 하지만, make bzlilo 와 zlilo 명령의 단점은 자신이 원하는 식으로 여러개의 커널을 선택해서 부팅할 수 있게 하기 위해서는 먼저 /etc/lilo.conf 를 수정했을 경우에 사용해야 효과가 있으며, 또한 x86 의 인텔 계열에서 사용 가능 합니다. 왜냐하면 x86 에서 lilo 를 사용하기 때문입니다. make install 명령을 따로 내릴 경우도 마찬가지로 x86 계열에서만 사용 가능 합니다. 위 에서의 make bzImage;make install;lilo 라고 실행 한다고 했는데, 사실 뒤의 lilo 명령은 make install 안에 들어 있는 내용이기 때문입니다. 수동으로 할 시에는 다음과 같이 합니다. [root@queenrjh linux]#cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-(커널버젼) [root@queenrjh linux]#mv /usr/src/linux/System.map /boot/System.map-(커널버젼) [root@queenrjh linux]#mv /boot/System.map /boot/System.map-(이전 커널버젼) 간혹 커널에 이상이 발생하면, 화면에 여러 가지 레지스터들과 그 16진수 내용에 대한 한 페이지 의 정보가 출력됩니다. 만약에 System.map 이 있다면, klogd 는 16진수 주소를 그 주소가 나타 내는 함수 이름으로 변환합니다. 이 정보로 정확히 어느 위치에서 커널이 문제를 일으켰는지 판 단할 수 있습니다. 그런데, System.map 이 없다면, 거의 필요없는 16진수 주소를 보게 될 겁니다. 이 값들은 각 기계마다 다르고, 커널 설정마다 다릅니다. 하지만, 일반적으로 System.map 파일은 시스템의 부팅 시에는 어떠한 영향도 주지 않습니다. 단, System.map 파일이 없다면, 시스템에 문제가 발생할 때 주어지는 정보는 여러분이나 커널 개발자 에게 무엇이 문제인지에 대한 어떠한 단서도 주지 못 할 것이라는 경고 메세지만 뿌려 줍니다. 그렇다면 여기서 lilo.conf 를 한 번이라도 들여다 보신 분이나 편집해 보신 분이라면 커널 이미 지를 여러개를 등록시켜 사용하는 것을 본 경험이 있으나, System.map 은 어떻게 각 커널에 맞게 사용해야 하는지 의문을 가지실 것입니다. 방법은 /etc/rc.d/init.d/syslog 파일에서 'daemon klogd' 로 시작하는 줄을 다음과 같이 고칩니 다. daemon klogd -k /boot/System.map-'uname -r' 커널 버전을 확인하여(uname -r), 'System.map' 뒤에 붙인 후, 그 파일명을 -k 옵션으로 klogd로 넘기는 것입니다. ------------------------------------------------------------------------------------------ 그리고, make zdisk 와 make
