사용자 정의 커널(Debian)용으로 컴파일하는 방법은 무엇입니까?

사용자 정의 커널(Debian)용으로 컴파일하는 방법은 무엇입니까?

version.h에 파일이 있습니다 /usr/include/linux. 많은 헤더 파일에 이 defines파일 이 포함되어 있으며 ifdefs.

그러나 내 커널을 컴파일할 때 이를 적절하게 반영하는 방법을 알 수 없습니다 version.h.

실제로 이것은 모든 커널 관련 헤더 파일에 적용됩니다. AFAICS는 항상 실행 중인 커널이나 통과하는 /usr/include/linux커널이 아닌 배포판과 함께 제공되는 커널을 나타냅니다 .makeSYSSRC

과거에는 내 자신의 커널 소스에 대한 심볼릭 링크를 만드는 방법을 사용했지만 이것이 올바른 접근 방식이 아니라고 생각합니다.

이것이 어떻게 작동하나요? 사용자 정의 커널(예: 커널 모듈)에 대해 어떻게 컴파일합니까?

답변1

사용자 정의 커널에 맞게 시스템을 구성할 때 수정된 커널 소스의 현재 버전에 이름을 추가하는 것이 좋습니다.

예를 들어 Armbian에서는 자체 커널 패키지를 만들고 kernel.release에 -sunxi를 추가합니다.

4.6.3 커널 버전 수정을 예로 들어 보겠습니다.

root@ruir:/usr/src/linux-headers-4.6.3-sunxi# grep -ri 4.6.3-sunxi *
include/generated/utsrelease.h:#define UTS_RELEASE "4.6.3-sunxi"
include/config/kernel.release:4.6.3-sunxi

또한 커널 모듈의 경우 다음 위치에 있습니다 /lib/modules/4.6.3-sunxi/build.

include/generated/utsrelease.h:#define UTS_RELEASE "4.6.3-sunxi"
include/config/auto.conf.cmd:ifneq "$(KERNELVERSION)" "4.6.3-sunxi"
include/config/kernel.release:4.6.3-sunxi

(바라보다ARM/Arbian Jessie에 sysdig 설치 - 잘못된 커널 버전으로 컴파일된 모듈)

우리가 본 것처럼 이 작업은 다음에서 수행될 수 있습니다 uname -r.

$uname -r
4.6.3-sunxi

사용자 정의 커널 패키지의 경우:

$dpkg -l | grep sunxi
ii  linux-dtb-next-sunxi             5.16                                  armhf        Linux DTB, version 4.6.3-sunxi
ii  linux-firmware-image-next-sunxi  5.16                                  armhf        Linux kernel firmware, version 4.6.3-sunxi
ii  linux-headers-next-sunxi         5.16                                  armhf        Linux kernel headers for 4.6.3-sunxi on armhf
ii  linux-image-next-sunxi           5.16                                  armhf        Linux kernel, version 4.6.3-sunxi

자신만의 컴파일된 커널 헤더를 추가하는 방법에 대해서는 다음을 참조하겠습니다.커널 헤더 파일(굵은 글씨는 제가 강조한 것입니다.) 부 커널 버전을 교체하는 경우 make headers_install.

사용자 공간 프로그램

일반적으로 사용자 공간 프로그램은 배포판에서 제공하는 헤더 파일, 일반적으로 glibc-devel, glibc-kernheaders 또는 linux-libc-dev라는 패키지에서 빌드됩니다. 이러한 헤더 파일은 일반적으로 이전 커널 버전에서 가져온 것이며 glibc를 다시 빌드하지 않으면 안전하게 교체할 수 없습니다. 특히 /usr/src/linux/include 또는 /lib/modules/*/build/include/linux에 대한 심볼릭 링크로 /usr/include/linux를 설치하지 않는 것이 좋습니다. 응용 프로그램 재구축이 중단되는 경우가 많기 때문입니다. . 예를 들어, 이전 커널은 Arch/${arch}/include/asm 대신 include/asm-${arch}에 아키텍처별 헤더 파일이 있고 아키텍처별 디렉터리에 대한 심볼릭 링크가 있습니다.

배포용 헤더를 패키징하는 올바른 방법은 커널 소스 디렉터리에서 "make headers_install"을 실행하여 헤더를 /usr/include에 설치한 다음 특정 버전에 대해 방금 설치된 커널 헤더에 의존하여 C 라이브러리 패키지를 다시 빌드하는 것입니다. .

예를 들어 프로그램이 패치된 커널이나 최신 커널에서만 실행되기 때문에 일부 커널 헤더 파일의 특정 버전에 의존하는 사용자 공간 프로그램을 배포하는 경우 /usr/include에 있는 헤더 파일을 사용할 수 없습니다. 또한 /usr/src/linux/include 또는 /lib/modules/*/build/include/에 있는 헤더 파일은 사용자 공간에 포함할 준비가 되어 있지 않기 때문에 사용할 수 없습니다. 이것을 시도하면 커널이 경고하고 이 위키 페이지를 알려줄 것입니다. 이 문제를 해결하는 올바른 방법은 새 커널에 패치된 단일 헤더 파일과 같이 필요한 특정 인터페이스를 분리하여 프로그램에서 사용하는 문자 장치에 ioctl 번호를 제공하는 것입니다. 자신의 프로그램에 이 소스 파일의 복사본을 추가하고 새 커널 버전과 동기화를 유지해야 한다는 점에 유의하세요. 귀하의 프로그램이 GPLv2에 따라 라이선스가 부여되지 않은 경우 파일 작성자로부터 자신의 프로그램 라이선스에 따라 배포할 수 있는 허가를 받았는지 확인하십시오. 이제 프로그램은 일반 커널에는 없을 수 있는 커널 인터페이스에 의존하므로 커널이 인터페이스를 이해하고 이전 인터페이스로 돌아가지 않고 유용한 오류 메시지를 제공하는지 확인하기 위해 런타임 검사를 추가하는 것이 좋습니다.

커널 개발에도 유용합니다. 또는 여러 커널 버전이 설치된 다른 커널이나 다른 서버용 커널/모듈을 컴파일할 때 SYSSRC를 사용하여 대체 커널 소스 위치를 지정할 수 있습니다.

관련 정보