이것이 사람들이 왜 다른 것을 사용하기로 선택하는지에 대한 현재의 이해입니다. 저를 확인하거나 수정해 주실 수 있습니까?
- 런타임과 컴파일 시간: 런타임에 이 기능을 활성화할지 여부를 모르는 경우 tristate를 사용하세요. 그렇지 않으면 컴파일 타임에 알 수 있으므로 bool을 사용하십시오. 일부 주변 코드 B에 일부 선택적 코드 A를 포함하는 경우 (예: GPU 지원과 같은 추가 기능을 포함하기 위해) 전체 모듈 B가 3 상태
#ifdef
로 선언될 수 있더라도 A를 bool로 설정해야 합니다.ifdef
컴파일 타임에 완료됩니다. - 반복 속도: 새로운 코드를 개발하는 경우 이를 모듈로 선언하면 전체 시스템을 다시 시작하지 않고도 이전 버전을 빠르게 언로드하고 새로 컴파일된 버전을 다시 로드할 수 있습니다.
- 침입성: 이미 실행 중인 코어(예: 대칭 다중 처리)에 동적으로 추가된 일부 코드는 파괴적이므로 항상 부울입니다.
여기에 내가 놓친 다른 요소가 있습니까? 제가 놓친 요소는 아마도
- 성능
- 안전
- 경험 법칙(예: "다음이 아닌 이상 항상 bool을 사용하십시오.필요삼국지 사용")
다른 설명, 메모, 링크 및 아이디어를 제공해 주시면 대단히 감사하겠습니다. 감사해요!
답변1
인용문https://www.linuxjournal.com/content/kbuild-linux-kernel-build-system
커널의 모든 항목을 모듈로 컴파일할 수는 없습니다.
많은 기능은 너무 방해가 되므로 컴파일 타임에 커널이 해당 기능을 지원하는지 여부를 결정해야 합니다. 예를 들어, 실행 중인 커널에 SMP(대칭적 다중 처리) 또는 커널 선점 지원을 추가할 수 없습니다. 따라서 부울 구성 표기법을 사용하는 것은 이러한 유형의 기능에 적합합니다.
모듈로 컴파일할 수 있는 대부분의 기능은 컴파일 타임에 커널에 추가할 수도 있습니다. 이것이 바로 내장 함수를 컴파일할지(y), 모듈로 컴파일할지(m), 전혀 컴파일하지 않을지(n) 결정하기 위한 3상태 기호가 존재하는 이유입니다.
나는 이것이 분명하다고 생각합니다. 선택 사항이 두 개뿐이라면 부울을 사용하고, 선택 사항이 세 개라면 tristate를 사용하세요. 다른 모든 것은 의미가 없습니다.