내가 받은 편지로 판단해 볼 때, System.map 파일은 여전히 사람들에게는 어려운 것 같다. 그래서 커널 메일링 리스트에서 그 파일에 대한 긴나긴 토론들을 읽어보았다.
Q. 그것은 어떤 용도로 사용됩니까?
A. 만약 커널 oops가 발생하면, 화면에 여러 가지 레지스터들과 그 16진수 내용에 대한 한 페이지의 정보가 출력될 것입니다. 만약 System.map이 있다면, klogd는 16진수 주소를 그 주소가 나타내는 함수 이름으로 변환할 것입니다. 이 정보로부터 정확히 어느 위치에서 커널이 문제를 일으켰는지 판단할 수 있습니다. System.map이 없다면, 완전히 쓸모없는 16진수 주소들만을 떠맡게 될 것입니다. 이 값들은 각 기계마다 다르고, 커널 설정마다 다르기 때문입니다.
Q. 그렇다면 그 파일 없이도 살 수 있습니까?
A. 리눅스는 System.map 없이 부팅할 것입니다. 그러나 시스템에 문제가 발생할 때, 주어지는 정보는 당신에게나 커널 개발자에게도 무엇이 문제인지에 대한 어떠한 단서도 주지 못 할 것이라는 경고를 합니다. System.map은 몇 백 Kb밖에 안 되고, 일단 설치한 후에는 완전히 잊어버리고 있어도 됩니다.
Q. 심볼릭 링크를 만들고 하는 모든 작업들이 너무 혼란스럽습니다.
A. Jeff Garzik께서 x86에서 사용자는 'make install' 할 수 있는다는 언급을 하신 편지를 보내주셨습니다. 이는 vmlinuz-VERSION과 System.map-VERSION을 /boot로 복사하고 lilo를 실행합니다. 미리 /etc/lilo.conf가 변경되어 있어야 합니다. (그리고 klogd의 시작 스크립트에서 'klogd -k /boot/System.map-`uname -r`'을 사용해야 합니다.)
또 몇몇 사람들은 명령행에 '-j n'을 추가하는 것에 (즉 `make -j 32 bzImage`) 대한 메세지를 보고 편지를 보냈다. 어떤 사람들은 단일 프로세서 시스템에서 그것의 유효성에 대해 질문했다.
난 64MB RAM의 K6-233 시스템에서 테스트를 했다. 작업의 수를 바꿔가면서 커널을 컴파일을 하였다. 동시 빌드의 수를 늘리면 커널 빌드는 더 빨라진다. 한계는 -j 32로 보인다. (빌드 시간을 거의 1분 정도 줄였다.) 이 이상은 거의 향상이 없는 것 같다. SMP 시스템에서 더 많은 이득을 볼 수 있는 것이 맞지만, 테스트는 단일 프로세서 시스템에서도 역시 -j는 유효한 팁이란 것을 보여준다.
Liviu Sas은 'nice --20 make bzImage' 또한 컴파일 속도를 높이는 유용한 팁이라는 제안을 보내주었다.
John Slee는 lilo.conf 자동 생성기를 보내주었다. 이 작은 스크립트는 /boot에서 모든 안정 커널을 찾아서 lilo.conf를 만든다. 가장 높은 버전의 커널을 기본값으로 잡는다.
기본으로 필요한 작업은 모든 lilo.conf에 포함될 옵션들을 가지고 있는 /etc/lilo.conf.static 파일을 만드는 것이다. 그 후, 아무 인자없이 스크립트를 실행하기만 하면 된다. lilo.conf를 만들고 새 부트로더를 설치한다.
내가 보기에 한 가지 단점은 부트 항목별로 옵션을 넣을 수 없다는 것이다.
#!/bin/bash umask 772 kernel_dir=/boot # lilo assumes the default image is the first one in lilo.conf, so # we sort the kernel images backwards, hence the highest-version'd kernel # will be the default. images=`cd $kernel_dir && ls -1 vmlinuz-* \ | egrep "vmlinuz-([0-9]+).([0-9]+).([0-9]+)[^-]*$" \ | sort -rn` cp -f /etc/lilo.conf.static /tmp/lilo.conf # three lines per entry, 3 x 19 images = 57 ( for img in $images ; do label=`echo $img | sed 's/vmlinuz/linux/ ; s/-//g ; s/\.//g'` echo "image=$kernel_dir/$img" echo "label=$label" echo "" done ) | head -57 >> /tmp/lilo.conf if /sbin/lilo -C /tmp/lilo.conf ; then mv -f /etc/lilo.conf /etc/lilo.conf.last cp -f /tmp/lilo.conf /etc/lilo.conf echo successfully installed new bootloader. rm -f /tmp/lilo.conf exit 0 else echo eek, lilo barfed rm -f /tmp/lilo.conf exit 1 fi
내가 받았던 편지에서 또 다른 흔한 주제는 커널 패치에 대한 기사에 관련된 것이다. 특히, 많은 사람들이 옛날 커널을 위해 작성된 패치를 새 커널에 적용하려는 데서 문제를 겪고 있다. 대부분의 경우, 패치 과정중에 어떤 경고 메세지를 받았고 패치가 어떻게 동작하는지 완전히 이해하지 못 한다면, 그 패치의 관리자에게 연락을 해서, 문제점에 대해 말해주어야 한다.
만약 'offset 31 lines'나 이 비슷한 메세지가 나왔다면, 이는 문제가 아니다. 파일에서 패치하려하는 루틴의 코드가 약간 변경되어지만, 목표 루틴은 발견되어 패치되었다는 것을 의미한다.