이에 따르면LWN 기사kdbus는 D-Bus를 대체할 것으로 예상됩니다. 어떻게든 확인할 수 있나요?
두 가지 모두 서로 다른 API가 있다고 생각하기 때문에 이것이 쉬운 작업이 될지 궁금합니다. 내가 이해하는 바에 따르면 프로그램을 D-Bus 사용에서 kdbus로 전환하려면 일부 작업/업데이트를 다시 수행해야 합니까? 따라서 LWN 기사에서 언급했듯이 D-Bus를 교체하는 것이 목표라면 업데이트 작업이 필요하지 않을까 싶습니다.
아니면 두 시스템이 동시에 작동할 때가 올까요?
답변1
기사에 대한 제 의견을 전해드리겠습니다.
kdbus는 D-Bus를 대체할 것으로 예상됩니다. 어떻게 든 확인할 수 있습니까?
그것은 명시적인 의도이지만 WRT에서 이를 "확인"하면 "예, 여기에 GNU/Linux의 미래에 대한 타임라인이 있습니다"라고 말할 수 있는 중앙 기관이 없습니다. 커널을 넘어서는 이질적이고 분산된 영역입니다. .
물론, 그것이 커널이라는 점을 고려하면, 탈중앙화 영역의 많은 의사결정자들은 아마도 협력에 관심을 가질 것입니다. 좋은 것 같습니다.
쉬운 일이겠지
두 가지를 동시에 사용할 수 없다는 표시는 없습니다.지금까지가장 건전한 형태의 전환. 따라서 "쉬움"은 상황에 따라 다릅니다.
둘 다 서로 다른 API를 가지고 있다고 상상해 보세요.
처음에 링크된 Greg KH 발표는 전환과 관련하여 매우 건전한 사용자 영역 호환성 레이어를 언급합니다. 처음에 일부 배포판에서는 두 가지를 모두 사용할 수 있게 만들고 다른 배포판에서는 호환성 계층으로 직접 이동하는 등의 작업을 수행했습니다.
때로는 이전 버전과의 호환성을 희생하면서 앞으로 나아가는 것이 좋습니다. Perl 5 대 Perl 4 또는 Python 3 대 2를 고려하십시오. 메이저 버전 내에서는 이전 버전과의 호환성을 최우선으로 개선(새로운 마이너 버전, 5.8, 5.9, 5.10 등으로 표시)이 이루어지며, 동시에 다음 메이저 버전(호환되지 않지만 훨씬 개선되었을 것으로 예상됨)에 대한 작업이 진행됩니다. 현재 버전의 경험을 바탕으로) 진행 중일 수 있습니다.
버전이 있는 배포판은 현재 버전이 유지 관리되고 업데이트되는 동안 새 버전에 대한 작업도 진행된다는 점에서 유사합니다. 이는 kdbus와 같은 근본적인 변경 사항의 통합을 더 쉽게 만듭니다. 무슨 일이 일어나는지 지켜봐야 할 것 같아요.