커널 컴파일 시간 절약

댓글에서 언급했듯이, make -j4보유한 CPU 코어 수와 같거나 약간 높은 숫자를 사용해야 합니다.

로컬 구성 변경

다음 지침은 업스트림에서 커널을 빌드하기 위한 것입니다. 개인적으로 이게 제일 쉬운 것 같아요. 우분투 패치가 적용된 트리를 얻는 방법을 모르겠습니다. 이렇게 빌드할 준비가 되었습니다.

(1) 이론적으로 보다 합리적인 기간 동안 테스트하기 위해 커널을 구축하는 방법은 다음과 같습니다.

cp /boot/config-`uname -r` .config

더 새로운 것을 활성화할 필요는 없습니다. 따라서 유일한 문제는 이름을 바꾸면 작동이 중단된다는 것입니다.

make oldnoconfig

현재 로드되지 않은 모든 모듈은 이제 비활성화됩니다. (필요한 모든 USB 장치를 연결했는지 확인하십시오...):

make localmodconfig

최근에 저에게 효과가 있었으므로 유용할 수 있습니다. 지난번에 시도해 봤는데 별로 좋지 않더군요.

1시간 정도에서 10분 정도로 단축한 것 같아요. 비록 make localmodconfig그것이 나에게 필요하지 않은 엄청난 양의 물건을 만들고 있음에도 불구하고 . OTOH는 실제로 이러한 항목(예: make xconfig)을 찾아 비활성화하는 데에도 시간이 걸립니다(또는 원하는 것을 실수로 비활성화한 경우 더 오래 걸립니다).하다필요).

나는 그 존재가 그만한 가치가 있다는 것을 알고 싶습니다. 단지 그것이 당신을 행복하게 해준다는 보장은 없습니다.

(2) 각 프로젝트를 구축하는 데 2시간이 걸릴 것이라고는 생각하지 않습니다.개정하다귀하의 "모듈"에. (새로운 시스템 호출을 구현하는 경우 실제로 내장 함수여야 합니다.) make수정된 파일만 다시 컴파일되어 커널 바이너리에 통합됩니다. 따라서 Kconfig를 올바르게 설정하는 것이 너무 큰 문제라면 빌드의 처음 2시간은 그다지 나쁘지 않을 수 있습니다.

배포 커널 소스 패키지를 사용하여 빌드하는 경우 이 문제가 발생할 수 있습니다. (수동 빌드로 전환하거나 소스 코드 패키지를 사용하여 배포를 속일 수 있습니다 ccache). 또는 수정으로 인해 불행하게도 많은 소스 파일에 포함된 헤더 파일이 수정될 수도 있습니다.

그럼에도 불구하고 다른 커널 버전으로 포팅하고, 실행하고, 다른 빌드 옵션을 테스트하려는 경우 git bisect사용자 정의 Kconfig(예: 더 작은 Kconfig)를 만드는 것이 유용할 수 있습니다.

동일한 머신에서 커널을 반복적으로 빌드하는 경우은닉처특히 가상 머신을 사용하는 경우 많은 도움이 될 수 있습니다. 내 경험에 따르면 가상 머신에서 동일한 프로젝트를 연속적으로 클린 빌드하는 데는 ccache가 없는 빌드에 비해 약 절반의 시간이 걸립니다. 첫 번째 빌드에서 저장된 개체 파일을 저장하려면 추가 디스크 공간이 필요합니다. 또한 ccache가 활성화된 첫 번째 빌드에서는 ~/.ccache모든 개체 파일을 폴더에 쓰는 데 약간 더 오래(5-10% 더 오래) 걸립니다.

내 빌드 머신의 설정 스크립트에 다음과 같은 내용이 있습니다.

sudo apt-get install ccache
for binary in gcc g++ cc c++ i686-linux-gnu-g++ i686-linux-gnu-gcc x86_64-linux-gnu-gcc x86_64-linux-gnu-g++
do
    if [[ -e /usr/bin/$binary ]]
    then
        sudo ln --symbolic /usr/bin/ccache /usr/local/bin/$binary
        test $? -eq 0 || echo error: symlinking $binary to ccache
    fi
done
echo "If you have the space, you may want to increase your ccache size with \"ccache -s 5G\" (or however much space you can afford)"