이것은 여담일 수도 있고 아닐 수도 있습니다. 그렇다면 댓글 남겨주시면 삭제하겠습니다.
저는 커널 개발자가 되려고 노력하고 있으며 메일링 리스트 중 일부를 읽는 동안 Linux 커널 개발자가 Linux 커널에서 개선점을 찾을 수 있는 곳이 어디인지 궁금해하지 않을 수 없었습니다. 커널의 버그 추적기를 살펴보면 실제로 커널 버그가 그리 많지 않으며 패치 중 상당수가 커널 내부 최적화 또는 개선과 관련되어 있습니다. 이는 개발자들이 Linux 커널에서 개선해야 할 사항을 어떻게 파악하는지에 대한 질문으로 이어집니다.
다시 한번 말씀드리지만 주제에서 벗어난 내용이라면 댓글 남겨주시면 삭제하겠습니다.
답변1
다른 답변(질문이 주제에서 벗어날 수 있거나 답변이 위키 답변으로 변환되어야 함을 암시할 수 있음)에 추가됩니다.
배포판에는 좋은 커널 개발자가 있는 경우가 많지만, 그럼에도 불구하고 대부분의 배포판에는 버그를 선별하고 적절한 사람에게 전달할 수 있는 지식이 풍부한 사람들이 있습니다. 단지 범용 배포판이라고 생각하지 마십시오. 아마도 커널을 사용하는 라우팅을 위한 openwrt와 같은 특수 배포판이 있습니다.다르게또는 모든 가상화된 이미지
많은 개발자들이 회사로부터 급여를 받습니다. 릴리스 빌드의 경우 개발자는 문제(버그를 암시할 수 있음)를 추가로 확인할 수 있습니다. 하드웨어 제조업체(장치 및 아키텍처)의 경우 추가 스트레스 테스트를 수행할 수 있습니다. 때로는 개발자들끼리 토론을 하다가 버그가 발생할 수도 있습니다. (부분마다 가정이 다를 수 있습니다.)
스택: 당신은 많은 것을 가지고 있습니다표준 라이브러리커널 시스템 호출을 직접 사용하는 프로그램. 그들은 아마도 광범위한 테스트를 수행했을 것입니다.
커널에는 다양한 테스트가 있으며, 그 중 다수는 커널이 개발(및 출시)됨에 따라 정기적으로 수행됩니다.
개발 및 디버깅: 코드를 변경하면(또는 코드를 보는 것만으로도) 커널의 관련되지 않은 부분에서 더 중요한 버그가 드러날 수 있습니다. 참고: 또한 코드를 보는 것만으로도(어쩌면 특정 부분을 개선하고 싶기 때문에 다른 부분이 코드를 어떻게 사용하는지 이해해야 할 수도 있습니다.)
얼마나 많은 다양한 기계와 용도가 있는지 과소평가하지 마십시오. 따라서 항상 새로운 버그가 나타날 것입니다. 참고: 개발자라면 다음과 같은 내용을 볼 수 있습니다.질문버그가 되기 전에 수정된 버그인지 새로운 버그인지 평가할 수도 있습니다.
참고: 버그 보고서를 제출하면 두 버그가 모두 수정되었습니다. 하나는 시스템 관리자(회귀)이고 두 번째는 Linus Torvalds(상위 수준)입니다. 첫 번째 오류는 일반 코드가 약하다는 것을 암시하기 때문입니다.
확인하다:https://kernelnewbies.org/어쩌면 하위 시스템별 메일링 리스트가 있어서 물어볼 수도 있습니다. 새로운 개발자를 기꺼이 도와주려는 사람들이 있을 것입니다.
답변2
오류를 찾는 방법에는 (적어도) 세 가지가 있습니다.
- 이 프로그램을 사용하는 사람들은 이 프로그램이 비정상적으로 동작한다는 것을 알 수 있습니다. 이는 그들이 원하는 기능일 수도 있고, 결함(예: 버그)일 수도 있습니다.
- 코드를 직접 살펴보면 코드의 광고된 동작(주석이나 문서 또는 동일한 코드의 다른 부분에서)과 실제 기능 간의 불일치로 결함이 발견될 수 있습니다. 또는 다음과 같이 우발적인 오용일 수도 있습니다. 배열 표시가 범위를 벗어났습니다. 이는 기계적 수단(예: 컴파일러 검사)이나 사람의 눈으로 수행할 수 있습니다.
- 외부 프로그램(종종 퍼저라고 함)은 코드를 무작위로 공격하여 코드가 불규칙하게 동작하도록 만들 수 있습니다.
커널 버그가 많지 않아서가 아니라 발견된 후 빠르게 수정되기 때문에 커널 버그가 많이 표시되지 않을 것입니다.
기능 요청과 버그의 차이점은 일반적으로 새로운 동작에 대한 새 코드를 추가하는 것과 관련된 반면, 버그는 기존 코드의 버그라는 것입니다. 최적화는 버그 수정일 수도 있고 새로운 기능일 수도 있습니다.
새로운 커널 개발자로서 최적화는 매우 어려울 수 있습니다.
(이미 제안한 대로) 가장 좋은 방법은 아마도 현재 지원되지 않거나 제대로 지원되지 않는 장치를 찾아 해당 장치에 대한 드라이버를 작성해 보는 것입니다.
그러나 변경의 필요성을 발견하지 않고 기존 커널 코드를 읽는 것 자체가 커널 개발에 들어가는 좋은 방법일 수 있습니다. 최적화에 대해 논의하고 새로운 최적화가 어떻게 작동하는지 이해하는 것도 중요합니다.
답변3
bugzilla.kernel.org 및 LKML은 수정하거나 개선해야 할 질문과 사항이 끝없이 쏟아지는 소스입니다.
아주 똑똑한 사람들도 있습니다. 그들은 코드를 읽고 더 효율적인 방법으로 다르게 수행할 수 있다는 것을 깨달았고, 그래서 우리는 성능을 향상시켰습니다.
답변4
이것은 활성 커널 개발자가 아닌 Linux 사용자 공간 개발자로서의 내 관점에서 나온 것이지만, 무언가를 달성하는 방법을 찾을 때 아직 메인라인 커널에 병합되지 않은 패치 세트가 있다는 것을 알게 될 것입니다.
예를 들어커널에 대한 전체 작업 격리 모드CONFIG_TASK_ISOLATION특정 사용 사례에 유용할 것 같지만, 내가 아는 한 아직 메인라인 커널에서는 검색되지 않았습니다.https://github.com/torvalds/linux조회수가 없습니다.
이러한 패치 세트를 메인라인 커널에 통합하려는 시도는 커널 개발자의 출발점이 될 수 있습니다.