(커널 해킹을 위한) 사용자 정의 커널을 구축하고 설치하는 방법을 배우는 동안 나는 역설을 발견했습니다.
이것에스택 교환 답변, 저자는 다음과 같이 지적합니다.
아래 지침에서 소스 트리 내의 경로는 [src]/whatever 형식을 취합니다. 여기서 [src]는 소스 코드가 설치된 디렉터리입니다(예: /usr/src/linux-3.13.3). 쓰기 권한 측면에서 소스 트리가 안전하게 유지되어야 하므로(루트가 소유해야 함) 이 su 루트를 수행할 수 있습니다.
그는 참고서에서 이렇게 언급했습니다.리눅스 커널에 대한 간략한 소개, Greg Krohartman은 다음과 같이 말했습니다.
이 경고는 이 책의 단계를 따를 때 기억해야 할 가장 중요한 사항입니다. 커널 소스 코드 다운로드, 압축 풀기, 커널 구성 및 빌드 등 이 책의 모든 작업은 컴퓨터에서 일반 사용자로 수행되어야 합니다. 새 커널을 설치하는 데 필요한 2~3개의 명령만 슈퍼유저(루트)로 실행해야 합니다.
그리고
커널 소스 코드는 /usr/src/linux/ 디렉토리에 배치하면 안 됩니다. 이는 새로운 사용자 정의 커널의 위치가 아니라 시스템 라이브러리가 빌드되는 커널의 위치이기 때문입니다. /usr/src/ 디렉터리 트리 아래에서는 커널 개발을 전혀 수행하지 말고 로컬 사용자 디렉터리에서만 수행하여 시스템에 나쁜 일이 발생하지 않도록 하십시오.
두 소스 모두 꽤 오래되었습니다. 현재 올바른 접근 방식은 무엇입니까?
답변1
/usr
"맞춤형"이 잘못된 경우:
남성:
/usr/src
Source files for different parts of the system, included with some packages for reference purposes. Don't work
here with your own projects, as files below /usr should be read-only except when installing software (optional).
/usr/src/linux
This was the traditional place for the kernel source. Some distributions put here the source for the default
kernel they ship. You should probably use another directory when building your own kernel.
man 파일 계층 구조:
/usr/
Vendor-supplied operating system resources. Usually read-only, but this is not required. Possibly shared between
multiple hosts. This directory should not be modified by the administrator, except when installing or removing
vendor-supplied packages.
/usr/include
이전 종속성은 다음과 같습니다 /usr/src/linux
.
/usr/include/linux
This contains information which may change from system release to system release and used to be a symbolic link
to /usr/src/linux/include/linux to get at operating-system-specific information.
따라서 커널 소스 코드는 /usr/src
수정이 아닌 참조일 뿐입니다.
빌드를 읽기 전용 이벤트로 전환할 수 있도록 Documentation/admin-guide/README.rst
옵션 이 표시 됩니다.O=
/usr/src/linux-VERSION
cd /usr/src/linux-4.X
make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
마찬가지로 .config 파일은 /home 아래에 생성됩니다.