Linux 모듈 API가 이전 버전과 호환되지 않는 이유는 무엇입니까?
Linux 모듈 API가 이전 버전과 호환되지 않는 이유는 무엇입니까? Linux 커널을 업데이트 한 후 업데이트 된 드라이버를 찾는 것이 답답합니다.
독점 드라이버가 필요한 무선 어댑터가 있지만 제조업체에서 약 7 년 전에이 장치를 중단했습니다. 코드가 매우 오래되었고 Linux 2.6.0.0 용으로 작성 되었기 때문에 최신 Linux 커널로 컴파일되지 않습니다. 나는 많은 Linux 배포판을 사용했지만 동일한 문제가 모든 곳에 있습니다. Linux 커널과 함께 배포되는 오픈 소스 드라이버가 있지만 작동하지 않습니다. 일부 사람들은 최신 Linux 커널과 호환되도록 이전 독점 코드를 수정하려고하지만 새 Linux 커널이 출시되면 코드와 호환되는 데 몇 달이 걸립니다. 그 시간 내에 또 다른 새 버전이 출시됩니다. 이런 이유로 새로운 Linux 커널로 업그레이드 할 수 없습니다. 때로는 배포판을 업그레이드 할 수도 없습니다.
답변
Greg Kroah-Hartman은이 주제에 대해 다음과 같이 썼습니다. https://www.kernel.org/doc/html/v4.10/process/stable-api-nonsense.html
C 코드 컴파일과 관련된 몇 가지 기술적 세부 사항 외에도 그는 결정을 내리는 몇 가지 기본 소프트웨어 엔지니어링 문제를 도출합니다.
Linux Kernel은 항상 진행중인 작업입니다. 이것은 여러 가지 이유로 발생합니다.
- 새로운 요구 사항이 있습니다. 사람들은 소프트웨어가 더 많은 작업을 수행하기를 원하기 때문에 우리 대부분은 업그레이드하고 최신의 뛰어난 기능을 원합니다. 기존 소프트웨어에 대한 재 작업이 필요할 수 있습니다.
- 수정이 필요한 버그가 발견되었습니다. 때로는 버그가 디자인 자체에 있으며 상당한 재 작업 없이는 수정할 수 없습니다.
- 소프트웨어 세계에서 새로운 아이디어와 관용구가 발생하고 사람들은 일을 수행하는 훨씬 쉽고 / 우아하고 / 효율적인 방법을 찾습니다.
이것은 대부분의 소프트웨어 에 해당되며 유지 관리되지 않는 소프트웨어는 느리고 고통스러운 죽음을 맞이 합니다. 당신이 묻는 것은 왜 유지되지 않는 오래된 코드가 여전히 작동하지 않는가?
이전 인터페이스가 유지되지 않는 이유는 무엇입니까?
이전 버전과의 호환성을 보장하려면 이전 (종종 "깨진"및 안전하지 않은) 인터페이스를 유지해야합니다. 물론 이것은 상당한 비용 이 들지 않는 한 이론적으로 가능합니다 .
Greg Kroah-Hartman의 글
Linux가 안정적인 소스 인터페이스를 유지해야한다면 새로운 인터페이스가 만들어 졌을 것이고 오래되고 손상된 인터페이스는 시간이 지남에 따라 유지되어야했을 것입니다. 이는 [개발자]를위한 추가 작업으로 이어졌습니다. 모든 Linux [개발자]가 자신의 시간에 자신의 작업을 수행하기 때문에 프로그래머에게 무료로 아무런 이득없이 추가 작업을 요청하는 것은 불가능합니다.
Linux는 오픈 소스이지만 유지 관리하는 데 개발자 시간이 제한되어 있습니다. 따라서 인력은 여전히 "비용"측면에서 논의 될 수 있습니다. 개발자는 시간을 보내는 방법을 선택해야합니다.
- 오래되거나 깨지거나 느리거나 안전하지 않은 인터페이스를 유지하는 데 많은 시간을 할애하십시오. 이것은 때때로 첫 번째 인스턴스에서 인터페이스를 작성하는 데 걸리는 시간을 두 배에서 세 배로 늘릴 수 있습니다.
- 이전 인터페이스를 버리고 다른 소프트웨어 관리자가 자신의 소프트웨어 를 [직무를 수행하고] 유지 하기를 기대 합니다.
균형 적으로 비닝 인터페이스는 (커널 개발자에게) 정말 비용 효율적 입니다. 개발자가 새로운 Wi-Fi 어댑터에 10 달러 를 지불 하지 않고 몇 달, 몇 년을 보내지 않는 이유를 알고 싶다면 ... 그게 그 이유입니다. 커널 개발자에게는 시간 / 비용 효과가 있으며 사용자 나 제조업체에게 반드시 비용 효율적이지는 않습니다.
Linux 커널에 몇 가지 (매우 사소한) 패치를 제공했지만 커널 개발자라고 생각하지는 않습니다. 그러나 내가 아는 것은 다음과 같습니다.
커널 버전 2.6.0.0 용으로 작성된 드라이버 는 커널 버전 2.6.39에서 발생한 BKL (Big Kernel Lock) 제거보다 이전 버전입니다.
BKL은 Linux가 여전히 단일 프로세서 (단일 코어, 단일 스레드) OS 였을 때 만들어졌습니다. SMP 지원이 추가 되 자마자 개발자는 BKL이 어느 시점에서 큰 병목 현상이 될 것이라는 것을 인식했지만 시스템에 총 코어 / 스레드가 몇 개만있는 한 다소 견딜 수있었습니다. 그러나 처음에는 슈퍼 컴퓨터에서 Linux를 사용하는 사람들에게 진짜 문제가되었고, 그래서이 작업은 BKL에 필요한 모든 것을보다 세분화 된 잠금 메커니즘으로 또는 가능하면 잠금없는 방법으로 대체하기 시작했습니다.
일반 데스크톱과 고전력 랩톱에서 두 자리 수의 코어가있을 수있는 최신 컴퓨터에서는 서버는 말할 것도없고 2.6.0 이전 버전과 호환되는 커널 모듈 API도 BKL을 구현해야합니다.
레거시 모듈에 "I want to take the BKL"이라고 표시되면 나머지 커널은 모듈이이 모듈로 무엇을 할 계획인지 전혀 알지 못하므로 이전 버전과의 호환성 메커니즘은 BKL을 대체하는 모든 잠금을 가져와야합니다. 모든 가능성을 다룰뿐입니다. 그것은 큰 성능 타격이 될 것입니다. 또한 새로운 잠금없는 방법은 기존 잠금을 확인해야합니다. 이는 처음에 잠금이 없다는 점을 무너 뜨립니다. 따라서 레거시 모듈이 실제로로드되지 않은 경우에도 이전 버전과의 호환성 메커니즘이 존재하면 시스템 성능이 저하됩니다.
최근에 Spectre / Meltdown 보안 패치는 커널 / 사용자 공간 경계를 넘을 때 발생해야하는 일에 큰 변화를 가져 왔습니다. Spectre / Meltdown 수정 사항이 구현되기 전에 컴파일 된 모든 모듈은 Post-Specre / Meltdown 커널에서 신뢰할 수 없습니다.
불과 2 주 전에 자동화로 보안 업데이트가 적용될 때 수동 전원 순환이 필요한 오래된 서버의 문제를 해결하고있었습니다. 이것은 이전에 여러 번 발생했으며 재현 가능했습니다. megasr자동 업데이트에 포함되지 않은 Spectre / Meltdown 패치 이전의 독점 스토리지 드라이버 의 아주 오래된 버전이 있다는 것을 알게되었습니다 . 드라이버를 최신 버전으로 업데이트 한 후 문제가 해결되었습니다. 그건 그렇고, 이것은 일반 RHEL 6.10 시스템에있었습니다.
또한 사후 Spectre / Meltdown 커널을 사용하여 독점적 인 Pre-Spectre / Meltdown 하드웨어 모니터링 드라이버를로드 할 때 서버가 충돌하는 것을 보았습니다. 이 경험을 바탕으로 저는 Spectre / Meltdown 수정이 분수령 이벤트로 취급되어야한다고 완전히 확신합니다. 커널과 모듈은 모두 이전 수정 버전이거나 모든 수정 이후 버전이어야합니다. 믹싱 및 매칭은 대기중인 시스템 관리자에 대한 슬픔과 자정 모닝콜로 이어집니다.
Spectre는 CPU 설계 수준의 문제 였기 때문에 "계속주는 선물"입니다. 어떤 사람들은 약점을 악용 할 수있는 새로운 방법을 찾고 커널 개발자는 공격을 차단할 방법을 찾아야합니다.
이는 2.6.0.0 호환 레거시 커널 모듈 API가 해결해야하는 큰 문제 중 두 가지에 불과합니다. 나는 다른 많은 것이 있다고 확신합니다.
그리고 더 철학적 인 측면이 있습니다. 생각해보십시오. Linux를 가능하게하는 것은 무엇입니까?
그것의 큰 부분은 개방형 하드웨어 사양 입니다. 하드웨어 사양이 공개되면 누구나 참여할 수 있습니다. 운영 체제의 소스 코드가 공개되어 있으므로 누구나 기여할 수 있습니다. 드라이버 코드가 오픈 소스 인 경우 하드웨어 프로그래밍 사양을 영업 비밀로 유지할 수 없습니다.
Linux 커널 개발자는 오픈 소스 모델을 믿는 경향이 있습니다. 그렇기 때문에 하드웨어 제조업체가 참여하기 위해 선호하는 방법은 드라이버를 오픈 소스하고 기본 커널 소스 배포판에 병합 한 다음 ( 그런 다음에 만 ) 사용자 가 참여하도록 설계 및 개발 선택을 한 이유입니다. 유지 관리에있어 전체 커널 개발자 커뮤니티의 이점을 얻을 수 있습니다.
이를 통해 하드웨어 설계자와 제조업체가이를 가능하게하는 인센티브를 제공합니다. 비밀로 유지하고 싶은 것이 있으면 ASIC 또는 필요한 경우 서명 된 펌웨어로 캡슐화하도록 노력하십시오. (후자의 경우 다른 사람에게 펌웨어 패키지를 재배포 할 수있는 권한을 부여하십시오.)
그러나 커널은 오픈 소스이기 때문에 커널 개발자는 다른 사람들이 독점 드라이버를 별도로 유지 하는 것을 정확히 막을 수 없습니다 . 그러나 그들도 그들을 돌볼 동기가 없습니다.
사실, 커널 디버깅에서 독점 바이너리 드라이버로 인한 추가 번거 로움은 커널 개발자가 독점 드라이버 개발에 관심 을 갖지 않도록 하는 인센티브입니다 . "그들은 내 작업을 더 어렵게 만들고, 특히 더 쉽게 만들기 위해 어떤 조치를 취해야합니까?"
따라서 커널 개발자는 일반적으로 그룹 / 커뮤니티로서 가장 유리한 작업을 수행 합니다 . 여기에 일부 모듈 API 변경이 포함되어 있으면 그렇게됩니다. 타사 드라이버는 방정식을 입력하지도 않습니다.