커널의 늘어난 양은 패치로 배포된다. 예를 들어, 여러분이 1.1.45버전을 가지고 있고
다른 어딘가에 `patch46.gz'이 있다고 하자. 이것은 여러분이 패치의
적용을 통해서 1.1.46버전으로 업그레이드 할 수 있다는 뜻이다. 여러분은 가장
먼저 소스 구조의 백업을 만들어야 할 것이다.(`make clean' 을 하고
`cd /usr/src; tar zcvf old-tree.tar.gz linux'라고 하면 여러분은 tar 압축
파일을 만들 수 있다).
위의 예에서 계속하면, 여러분이 `patch46.gz'을 /usr/src 에 가지고 있다고
가정하자. /usr/src로 들어가서 `zcat patch46.gz | patch -p0' 라고 한다.
(또는 패치가 압축되어있지 않다면 `patch -p0 < patch46'이라고 해도 된다). 그
것이 성공하든 안하든간에, 내용을 적용하고 있다는 소리를 들으며 윙하고 날
아가는 것(만약 여러분의 시스템이 느리다면 천천히 내려오는 것을)을 보게 될
것이다. 보통, 이 작업은 여러분이 읽기에는 너무 빨리 지나가서 그것이 제대
로 작동되고 있는건지 아닌지 확인할 수 없다. 그래서 패치할 때에 -s 플래그
를 사용함으로써 단지 에러 메세지만을 나오게 할 수 있다(여러분은 "내 컴퓨
터가 실제로 무언가 바꾸고 있구나!"라는 느낌밖에는 가질 수 없을 것이다. 하
지만 여러분이 원한다면...). 부드럽게 넘어가지 않는 부분들을 보기 위해서는
/usr/src/linux로 가서 .rej 확장자를 가진 파일을 보아라. 어떤 버전의 패치
는(구버전일수록 하급의 파일 시스템에서 컴파일되었다.) # 확장자를 가진 파
일에 거부된(실패한) 사항을 남겼다. 이들을 찾기 위해 `find' 명령어를 사용할 수도
있다.
find . -name '*.rej' -print
표준 출력으로 현재 디렉토리와 그 아래의 모든 서브 디렉토리에 있는 .rej 확장자를
가진 모든 파일들을 출력한다.
모든것이 제대로 되면, 3장과 4장에서 설명한 `make clean', `config', `dep'
를 실행한다.
패치 명령에는 약간의 옵션이 있다. 위에서 말한 것처럼, patch -s 는 에러 메세지
이외의 모든 메세지는 나오지 않게 한다. 만일 여러분이 여러분의 커널
소스를 /usr/src/linux 보다는 다른 장소에 가지고 있으려한다면, patch -p1
(그 디렉토리에서)는 패치한 것들을 말끔히 할 것이다. 다른 패치 옵션들은 메
뉴얼 페이지에 잘 설명되어 있다.
(알아둘 것 : 아래는 오래 된 커넬에게만 적용된다)
제기되는 가장 중요한 문제는 제대로 되지 않는 `config.in' 파일이 언제 생성되었나
하는 것이다. 이것은 여러분이 그 선택사항들을 여러분의 머신에 맞게
고쳐야하기 때문이다. 이것은 조심해서 해야 한다. 하지만 여전히 한가지가 이전
버전과 충돌한다. config.in.rej 파일을 보면서 고치고 원래의 패치에는 무엇이
남아 있는지를 보아라. 고쳐진것은 보통 그 행의 처음에 `+'와 `-'로 표시
가 된다. 그 행 주변을 보고 그들이 `y'나 `n' 어떤 것으로 되어 있는지 기억하라.
이제, config.in을 편집해서, `y'는 `n'로, `n'는
`y'로 적절히 바꾸기바란다.
patch -p0 < config.in.rej
를 실행해서 제대로 되었다고 나오면(실패가 없으면), 구성과 컴파일을 계속하고,
남아있는 config.in.rej 파일은 지워도 된다.
만일 `previously applied patch detected: Assume -R?'이라는 말이 나오면,
여러분은 아마 현재 버전 번호 아래의 것으로 패치를 적용하려고 하는 것일 것이다.
`y'라고 답하면, 여러분의 소스를 낮은 버전으로 되돌리려고 하는
것이므로 대부분은 실패할 것이다. 이렇게 되면, 여러분은 새로운 소스 구조 전체를
가져야만 한다.(처음에는 그렇게 나쁜 생각만은 아니다.).
패치를 되돌리려면(적용한 것을 되돌리려면), 원래 패치에서 `patch -R'을 사용하라.
패치가 정말 잘못되었을 때 가장 좋은 방법은 모두 끝내고 clean으로 다시 하는
것이다. 소스 구조의 테두리를 벗어나서(예를 들면 linux-x.y.z.tar.gz 파일들
중에 하나에서부터) 처음부터 다시 시작한다.
몇번의 패치 후에는, .orig 파일들이 쌓이기 시작할 것이다. 예를 들어, 내가 가지고 있던 한 1.1.51 트리는 1.1.48이었을 때 한번 청소했을 뿐이다. 반 메가 정도 저장되어 있는 .orig 파일들을 없애자.
find . -name '*.orig' -exec rm -f {} ';'
주의해서 하기 바란다. 거부사항을 위해서 #를 사용하는 패치 버전은
.orig대신에 (tilde)를 사용하라.
.orig 파일들을 없애는 더 좋은 방법은 GNU Xargs를 이용하는 것이다.
find . -name '*.orig' | xargs rm
또는 ``아주 확실하지만 약간 좀 화면출력이 많은'' 방법이 있다.
find . -name '*.orig' -print0 | xargs --null rm --
Linus의 배포물들 이외에도 다른 패치들이 있다.(나는 그들을 ``비표준''이라고 부른다.) 만일 여러분이 이것들을 적용한다면, Linus의 패치들은 제대로 작동하지 않을지도 모르고, 또 여러분은 이것을 되돌리기 위해서, 소스나 패치를 수정하거나, 새로운 소스 트리를 설치하거나, 아니면 위의 작업들을 섞어가며 해야 할 것이다. 이것은 아주 쓸모없는 일이 될 수 있다. 그래서 만약 여러분이 소스를 수정하기를 (아주 나쁜 결과가 나올 가능성을 가지고) 원하지 않는다면, Linus의 패치를 적용하기 전에 비표준 패치들을 되돌려 놓던가, 아니면 새 소스를 설치해야 한다. 그리고 나면, 비표준 패치들이 아직도 동작하는지 볼 수 있을 것이다. 만일 그들이 동작하지 않으면, 여러분은 이전 커널에 머물러 있거나, 하고자 하는 일을 할 수 있는 소스나 패치를 가지고 놀든가, 아니면 새로운 버전의 패치가 나올때까지 기다릴 수 있다.
표준 배포판이 아닌경우에 패치는 얼마나 일상적인 것일까? 여러분은 아마도 이 것에 대해 들어보았을 것이다. 나는 깜빡이는 커서를 정말 싫어하기 때문에 내 가상 콘솔을 위해서 깜빡임없는 패치를 사용한 적이 있다.(이 패치는 새 커널 버전에서는 빈번히 업데이트된다.(적어도 전에는 그랬다.)). 가장 새로운 장치 드라이버들은 적재가능 모듈로 개발되고 있는 것과 동시에 빈번한 ``비표준'' 패 치도 확실히 줄어들고 있다.