저는 buildroot를 사용하여 임베디드 장치에서 실행되는 애플리케이션 코드를 작성할 수 있는 커널, 루트 파일 시스템 및 크로스 컴파일러를 성공적으로 만들었습니다. 현재는 장치 드라이버를 작성할 필요가 없고 어떻게 해야 할지 모르지만 앞으로는 필요할 수도 있습니다. 연구를 통해 커널 API가 버전 간에 변경될 수 있다는 점과 사용자 수준 응용 프로그램 작성과 달리 장치 드라이버 작성은 커널 버전에 따라 다르다는 사실을 알게 되었습니다. 기본적으로 나는 알고 싶습니다:
- 위 내용이 맞나요?
- 사용할 커널 버전을 결정할 때 어떤 요소를 고려해야 합니까?
내가 이 질문을 하는 이유는 내가 이 주제에 관해 읽은 모든 것(그리고 임베디드 Linux 강좌를 수강한 것)에서 커널의 2.6.x 버전을 언급하기 때문입니다. 3.6.11 커널을 사용하여 임베디드 시스템을 구축하고 있는데 왜 강좌와 문헌에서 이러한 이전 커널을 참조하는 것 같은지 궁금합니다. 이전 버전의 커널을 사용하면 어떤 이점이 있습니까, 아니면 최신 버전을 사용하면 어떤 단점이 있습니까?
답변1
3.x는 2.x의 연속일 뿐입니다. Linus는 한때 해당 버전의 "x" 부분이 너무 크다고 생각했습니다. 일반적으로 말하자면, 아마도 다음과 같은 라벨이 붙은 상당히 최신 커널이 필요할 것입니다."긴". 애플리케이션에 따라 많은 부분이 달라집니다. 커널의 원격 보안 취약점은 매우 드물지만 로컬 문제는 더 일반적입니다.
답변2
커널을 선택하는 것은 제약의 문제입니다:
- 커널은 실행 중인 하드웨어(예: NIC 드라이버)를 안정적으로 지원할 만큼 충분히 새 것이어야 합니다.
- 커널은 사용하려는 소프트웨어 기능(예: iptables)을 안정적으로 지원할 만큼 충분히 새로운 것이어야 합니다.
- 커널은 가능한 한 많은 취약점을 제거할 수 있을 만큼 새로운 것이어야 합니다.
- 커널은 신뢰성이 입증될 만큼 오래되어야 합니다("최첨단"이라는 말이 있습니다).
- 커널은 장기간 업데이트를 받을 수 있는 시리즈여야 합니다(한 번 배포된 시스템이 업데이트될 가능성이 없는 경우는 별 문제가 되지 않지만 #4와 #3을 더 심각하게 받아들여야 합니다).
목록을 살펴보면 실제로 요구 사항을 충족하는 커널 목록이 매우 작은 경향이 있으므로 솔루션이 명확한 경우가 많습니다.
답변3
최신 안정 커널을 사용할 수는 없나요? 장치 드라이버의 오래된 소스 코드가 있는 경우 장치 이름이 일치하는지 확인해야 한다고 생각합니다(예: /dev/eth0- /dev/enp2s0f0> 이것이 왜 좋은지 아직도 모르겠습니다).