본문 바로가기

linux kernel documentation

[Linux Kernel] 리눅스 커널 개발 가이드: Followthrough 자, 이제 당신이 작업한 내용을 패치로 보내기까지 했다. 커널 개발자들이 (심지어 숙련된 개발자들도) 가장 많이 실수하는 것은 패치를 보냈다고 모든게 끝났다고 생각하는 것이다. 사실은, 패치를 보내는 것은 다음 단계를 밟는 것이고 아직 할일이 더 남았다. 패치를 처음 보내자마자 더 이상 개선할 점이 없고 바로 머지되는 경우는 매우 드물다. 커널 개발 프로세스는 이 사실을 잘 알고, 게시된 패치를 개선한다. 당신은 코드를 작성한 사람으로서 당신의 코드가 커널의 품질에 맞게 개선되도록 책임을 져야한다. 이 단계에서 실패하면 메인라인에 머지되지 않을 것이다. 6.1 Working with reviewers 의미가 있는 패치는 다른 개발자들이 코드를 리뷰하면서 코멘트를 남길 것이다. 리뷰어와 함께 일하는 것은 .. 더보기
[Linux Kernel] 리눅스 커널 개발 가이드: Getting the code right 4. Getting the code right — The Linux Kernel documentation 4.1.1. Coding style The kernel has long had a standard coding style, described in Linux kernel coding style. For much of that time, the policies described in that file were taken as being, at most, advisory. As a result, there is a substantial amount of co www.kernel.org 커뮤니티와 함께 설계를 하는 것도 할 이야기가 많지만, 모든 커널 개발 프로젝트의 증명은 결과적으로 코드가 한다. 다른 .. 더보기
[Linux Kernel] 리눅스 커널 개발 가이드: Early-stage planning 3. Early-stage planning — The Linux Kernel documentation When contemplating a Linux kernel development project, it can be tempting to jump right in and start coding. As with any significant project, though, much of the groundwork for success is best laid before the first line of code is written. Some time spent www.kernel.org 리눅스 커널 개발을 할때, 바로 코딩부터 시작하려는 욕심이 들 수도 있다. 하지만 대부분의 중요한 프로젝트가 그렇듯, 프로젝트.. 더보기
[Linux Kernel] 리눅스 커널 개발 가이드: Introduction A guide to the Kernel Development Process — The Linux Kernel documentation © Copyright The kernel development community. www.kernel.org Introduction 이 문서는 커널 개발 프로세스와 개발자나, 고용주들이 개발에 참여하면서 겪는 좌절에 대해 다룬다. 커널 코드가 “mainline”에 머지되어야 할 이유는 많다. 코드가 mainline에 머지되어야 사용자들이 편하게 사용할 수 있고, 기여한 코드가 커뮤니티로부터 유지보수 받고, 커널 개발의 방향에 영향을 줄 수 있다. 리눅스 커널에 기여된 코드는 반드시 GPL 호환 라이선스여야 한다. 1.1 Executive summary (링크는 번역 후 추.. 더보기