F/R/E/E/4/U

글쓴이: Dave Jones <dave [at] ext2 [dot] net>
옮긴이: 임종균 <hermes44 [at] secsm [dot] org>
원문: http://ext2.linuxberg.com/99/07/kernel/070699-kernel1.shtml

내가 받은 편지로 판단해 볼 때, 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 시스템에서 테스트를 했다. 작업의 수를 바꿔가면서 커널을
컴파일을 하였다. 동시 빌드의 수를 늘리면 커널 빌드는 더 빨라진다.
한계는 -j32로 보인다. (빌드 시간을 거의 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'나 이 비슷한 메세지가 나왔다면, 이는 문제가 아니다.
파일에서 패치하려하는 루틴의 코드가 약간 변경되어지만, 목표 루틴은 발견되어
패치되었다는 것을 의미한다.

관련 링크: http://kldp.org/Translations/html/Kernel_Tip_2-KLDP/Kernel_Tip_2-KLDP.html