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