커널 내부에서 커널 모듈을 컴파일하면 어떤 이점이 있습니까?

때에 따라 다르지. 메모리 양이 더 적은 경우 모듈을 사용하면 매번 다시 로드되지 않으므로 이력서가 향상될 수 있습니다(2GiB RAM에서는 중요하지만 기존 하드 드라이브의 4GiB에서는 중요하지 않음). 이는 배터리 모듈(컴파일되었거나 모듈로서)의 일부 버그로 인해 부팅 시간이 긴 경우(몇 분) 특히 그렇습니다. 젠투에 버그가 없었음에도 커널을 정적으로 컴파일하는 것에서 모듈로 변경하는 것만으로 (보고된 대로) 시간을 systemd-analysis33초에서 18초로 줄일 수 있었고 "놀랍게도" 커널 부팅 시간이 9초에서 1.5초로 변경되었습니다. .

또한 모듈은 어떤 하드웨어를 사용하고 싶은지 모를 때 확실히 유용합니다.

추신. initrd에 중요한 드라이버를 포함하는 한 이를 모듈로 컴파일할 수 있습니다. 예를 들어 배포판에는 설치 시 initrd에 / 파일 시스템, 하드 드라이브 등이 포함됩니다.

제가 아는 한 속도에는 별 차이가 없습니다.

할당 단위가 한 페이지이기 때문에 몇 kB의 커널 메모리를 얻을 수 있다고 생각하므로 일반적인 아키텍처에서는 평균적으로 모듈당 약 2kB(1/2페이지)를 낭비하게 됩니다. 임베디드 시스템에서도 이는 별 의미가 없습니다. 또한 모듈을 커널과 동시에 압축할 수 있으므로 약간의 디스크 공간을 확보할 수 있습니다. 이는 저장 공간이 거의 없는 임베디드 시스템에 더 적합할 수 있습니다.

모듈을 모두 버릴 수 있다면 약간의 커널 메모리(모듈 로더가 필요하지 않음), 디스크 공간(모듈 유틸리티가 필요하지 않음) 및 시스템 복잡성(배포판의 기능으로 모듈을 로드할 필요가 없음)을 절약할 수 있습니다. 이러한 점은 하드웨어를 확장할 수 없는 일부 임베디드 설계에서는 상당히 매력적입니다.

몇 가지 잠재적인 이점이 있습니다. 성능은 논쟁의 여지가 있는 문제입니다. 동적 로더와 관련된 런타임 오버헤드 중 일부를 피할 수 있지만 실시간 스케줄러에 의존하지 않는 한 큰 문제는 아닐 것으로 생각됩니다.

시스템에서 거대한 페이지를 활용하는 경우 더 큰 정적 커널 이미지를 생성하면 페이지 설명자 캐시를 더 효율적으로 사용할 수 있습니다. 일부 시스템은 커널을 "케이지"하여 단일 메모리 위치에 단단히 압축하여 사소하고 심각한 페이지 오류로 인한 대기 시간을 일부 완화할 수 있습니다.

구조적으로 말하면 하나의 큰 이미지를 제공하는 것이 적합할 수 있습니다. 독립 모듈 수가 적을수록 유지 관리가 더 쉽고 유연성 손실이 크지 않다고 생각하기 때문입니다. 이러한 추론의 대부분은 스타일과 실천의 문제와 관련됩니다.

커널에 내장된 하드웨어의 모든 드라이버를 정적으로 컴파일합니다. 비영구적인 하드웨어(예: USB 연결 하드웨어)는 예외입니다.

내 하드웨어 구성이 조만간 변경될 가능성이 낮으므로 모듈에는 관심이 없습니다.