요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
해결할 문제를 정확히 정의하기
3.Early-stage.rst:13-69성공적인 kernel enhancement는 해결할 문제의 명확한 설명에서 시작한다. 특정 hardware의 driver처럼 문제가 분명한 경우도 있지만, 실제 문제와 자신이 생각한 해결책을 혼동하면 개발 방향이 잘못될 수 있다.
Linux audio와 LSM 사례
과거 Linux audio 개발자들은 system latency 때문에 application에 dropout이나 artifact가 생기지 않게 하려 했다. 그들이 구현한 해결책은 Linux Security Module framework에 연결해 특정 application에 realtime scheduler 접근 권한을 주는 kernel module이었다.
Audio 개발자에게는 당장의 문제가 해결되었지만 넓은 kernel community는 이를 LSM의 오용으로 보았다. LSM은 원래 process에 없던 privilege를 새로 부여하기 위한 framework가 아니며 system stability도 해칠 수 있다는 판단이었다.
커널 개발자들은 단기적으로 rlimit mechanism을 통해 realtime scheduling access를 제어하고, 장기적으로 커널 전체 latency를 줄이는 방향을 선호했다. 그러나 audio 쪽은 이미 구현한 module 밖의 대안을 받아들이지 않았고, 갈등 끝에 커널 개발 절차 전체에 실망했다.
실제 차이는 사용자 요구를 무시해서가 아니라 system stability, 장기 유지관리와 올바른 일반 해법을 더 중요하게 본 데 있었다. 교훈은 특정 구현에 집착하지 말고 문제 자체에 집중하며, 많은 code를 만들기 전에 community와 논의하라는 것이다.
- 정확히 어떤 문제를 해결해야 하는가?
- 그 문제의 영향을 받는 사용자는 누구이며 어떤 use case를 다뤄야 하는가?
- 현재 커널은 그 문제를 해결하는 데 어떤 점이 부족한가?
이 질문에 답한 뒤에야 가능한 solution을 비교하는 것이 의미가 있다.
구현 전에 community와 논의하기
3.Early-stage.rst:71-123초기 discussion은 이미 커널에 있는 기능을 중복 구현하는 일을 막는다. Linux는 크고 문서가 완벽하지 않아 기존 capability를 놓치기 쉽다. 원문 저자는 기존 driver의 존재를 모른 채 동일한 완성 driver가 게시된 사례를 보았다고 설명한다. 기존 기능을 다시 만든 code는 낭비일 뿐 아니라 mainline에도 받아들여지지 않는다.
제안한 solution의 일부가 mainline 기준에 맞지 않을 수 있다. code를 다 작성한 뒤보다 설계 단계에서 이를 발견하는 편이 훨씬 싸다. 이미 같은 문제를 고민한 개발자가 더 나은 생각을 갖고 있거나 구현을 도울 수도 있다.
닫힌 개발에서 문제가 늦게 드러난 사례
- Devicescape network stack은 single-processor system만 고려했다. multiprocessor에 맞게 locking을 뒤늦게 추가해야 했고, 현재 mac80211인 code의 merge가 1년 넘게 지연되었다.
- Reiser4는 core developer가 VFS layer에 있어야 한다고 본 기능을 file system 내부에 넣었고, 사용자가 유발할 수 있는 deadlock 없이 구현하기 어려운 기능도 포함했다. 문제가 늦게 드러나고 일부 수정이 거부되면서 mainline 밖에 남았다.
- AppArmor는 내부 VFS data structure를 안전하지 않고 신뢰하기 어려운 방식으로 사용했다. 이 문제를 포함한 여러 우려 때문에 수년 동안 mainline에 들어가지 못했다.
세 사례 모두 kernel developer와 일찍 논의했다면 많은 고통과 추가 작업을 피할 수 있었다.
누구에게 이야기할 것인가
3.Early-stage.rst:125-165계획을 공개하기로 했다면 관련 mailing list와 maintainer를 찾아야 한다. 첫 출발점은 MAINTAINERS 파일이다. 적합한 subsystem list가 있다면 일반 linux-kernel보다 해당 list가 더 전문적인 개발자에게 닿고 대화 환경도 더 적절할 수 있다.
MAINTAINERS가 항상 최신인 것은 아니고 모든 subsystem이 완전하게 표현되어 있지도 않다. 등록된 사람이 현재 실제 역할을 수행하지 않을 수도 있다. 이때 git log로 해당 code에서 최근 patch를 작성한 사람과 Signed-off-by를 붙인 사람을 확인하면 실제 활동 중인 담당자를 찾을 수 있다.
scripts/get_maintainer.pl -f path/to/file
scripts/get_maintainer.pl your-change.patch-f option은 file이나 directory의 maintainer 후보를 찾는다. 더 권장되는 방식은 patch를 argument로 주어 실제 변경 내용을 기준으로 Cc할 사람을 계산하는 것이다. 공격적인 검색 option은 수정 code에 실질적 관심이 없는 사람까지 넣을 수 있으므로 조심해야 한다.
다른 방법이 모두 실패하면 특정 code의 maintainer를 찾기 위해 Andrew Morton에게 문의하는 것도 효과적일 수 있다.
언제 계획을 게시할 것인가
3.Early-stage.rst:167-190가능하다면 초기 단계에 문제와 구현 계획을 게시하는 편이 좋다. 제공하는 정보가 구체적일수록 community가 유용한 의견을 줄 수 있다.
이 단계에서 가장 낙담하기 쉬운 반응은 적대적 비판이 아니라 아무 반응도 없는 것이다. 커널 개발자는 바쁘고, code나 실제 구현 가능성이 없는 거대한 계획도 많으며, 누구도 다른 사람이 게시한 idea를 의무적으로 review하지 않는다. 고수준 설계에서는 구현해야만 보이는 문제가 숨기도 하므로 개발자는 code를 보고 싶어 한다.
RFC에 comment가 적다고 project에 관심이 없다고 단정해서도 안 되고, 문제가 없다고 생각해서도 안 된다. 이런 경우에는 구현을 진행하되 진행 상황을 community에 계속 알리는 것이 가장 낫다.
회사 내부의 공개 승인
3.Early-stage.rst:192-224기업 환경에서 하는 kernel work라면 회사의 계획이나 code를 public mailing list에 게시하기 전에 권한 있는 manager의 허가가 필요하다. GPL-compatible license로 공개 승인을 받지 않은 code를 게시하면 특히 문제가 크다. management와 legal team이 일찍 합의할수록 모든 참여자가 안전하다.
아직 공식적으로 존재가 공개되지 않은 제품을 지원하는 kernel code라면 public discussion이 어려울 수 있다. 먼저 실제로 secrecy가 필요한지 검토해야 하며, 단순 관행 때문에 개발 계획을 닫아 두는 경우도 많다.
실제로 초기 공개가 불가능한 경우도 있다. 경험 많은 kernel developer를 보유한 회사는 나중의 integration 문제를 피할 수 있다고 판단해 내부에서 진행할 수 있다. 그런 전문성이 없다면 NDA 아래 외부 kernel developer에게 계획을 review받는 방법이 있다.
원문은 Linux Foundation의 NDA program을 이런 상황을 위한 수단으로 소개한다. Public disclosure 없이도 초기 설계의 심각한 문제를 피할 수 있을 만큼의 review를 받을 수 있다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. _development_early_stage:
Early-stage planning
====================
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 in early planning and
communication can save far more time later on.
Specifying the problem
----------------------
Like any engineering project, a successful kernel enhancement starts with a
clear description of the problem to be solved. In some cases, this step is
easy: when a driver is needed for a specific piece of hardware, for
example. In others, though, it is tempting to confuse the real problem
with the proposed solution, and that can lead to difficulties.
Consider an example: some years ago, developers working with Linux audio
sought a way to run applications without dropouts or other artifacts caused
by excessive latency in the system. The solution they arrived at was a
kernel module intended to hook into the Linux Security Module (LSM)
framework; this module could be configured to give specific applications
access to the realtime scheduler. This module was implemented and sent to
the linux-kernel mailing list, where it immediately ran into problems.
To the audio developers, this security module was sufficient to solve their
immediate problem. To the wider kernel community, though, it was seen as a
misuse of the LSM framework (which is not intended to confer privileges
onto processes which they would not otherwise have) and a risk to system
stability. Their preferred solutions involved realtime scheduling access
via the rlimit mechanism for the short term, and ongoing latency reduction
work in the long term.
The audio community, however, could not see past the particular solution
they had implemented; they were unwilling to accept alternatives. The
resulting disagreement left those developers feeling disillusioned with the
entire kernel development process; one of them went back to an audio list
and posted this:
There are a number of very good Linux kernel developers, but they
tend to get outshouted by a large crowd of arrogant fools. Trying
to communicate user requirements to these people is a waste of
time. They are much too "intelligent" to listen to lesser mortals.
(https://lwn.net/Articles/131776/).
The reality of the situation was different; the kernel developers were far
more concerned about system stability, long-term maintenance, and finding
the right solution to the problem than they were with a specific module.
The moral of the story is to focus on the problem - not a specific solution
- and to discuss it with the development community before investing in the
creation of a body of code.
So, when contemplating a kernel development project, one should obtain
answers to a short set of questions:
- What, exactly, is the problem which needs to be solved?
- Who are the users affected by this problem? Which use cases should the
solution address?
- How does the kernel fall short in addressing that problem now?
Only then does it make sense to start considering possible solutions.
Early discussion
----------------
When planning a kernel development project, it makes great sense to hold
discussions with the community before launching into implementation. Early
communication can save time and trouble in a number of ways:
- It may well be that the problem is addressed by the kernel in ways which
you have not understood. The Linux kernel is large and has a number of
features and capabilities which are not immediately obvious. Not all
kernel capabilities are documented as well as one might like, and it is
easy to miss things. Your author has seen the posting of a complete
driver which duplicated an existing driver that the new author had been
unaware of. Code which reinvents existing wheels is not only wasteful;
it will also not be accepted into the mainline kernel.
- There may be elements of the proposed solution which will not be
acceptable for mainline merging. It is better to find out about
problems like this before writing the code.
- It's entirely possible that other developers have thought about the
problem; they may have ideas for a better solution, and may be willing
to help in the creation of that solution.
Years of experience with the kernel development community have taught a
clear lesson: kernel code which is designed and developed behind closed
doors invariably has problems which are only revealed when the code is
released into the community. Sometimes these problems are severe,
requiring months or years of effort before the code can be brought up to
the kernel community's standards. Some examples include:
- The Devicescape network stack was designed and implemented for
single-processor systems. It could not be merged into the mainline
until it was made suitable for multiprocessor systems. Retrofitting
locking and such into code is a difficult task; as a result, the merging
of this code (now called mac80211) was delayed for over a year.
- The Reiser4 filesystem included a number of capabilities which, in the
core kernel developers' opinion, should have been implemented in the
virtual filesystem layer instead. It also included features which could
not easily be implemented without exposing the system to user-caused
deadlocks. The late revelation of these problems - and refusal to
address some of them - has caused Reiser4 to stay out of the mainline
kernel.
- The AppArmor security module made use of internal virtual filesystem
data structures in ways which were considered to be unsafe and
unreliable. This concern (among others) kept AppArmor out of the
mainline for years.
In each of these cases, a great deal of pain and extra work could have been
avoided with some early discussion with the kernel developers.
Who do you talk to?
-------------------
When developers decide to take their plans public, the next question will
be: where do we start? The answer is to find the right mailing list(s) and
the right maintainer. For mailing lists, the best approach is to look in
the MAINTAINERS file for a relevant place to post. If there is a suitable
subsystem list, posting there is often preferable to posting on
linux-kernel; you are more likely to reach developers with expertise in the
relevant subsystem and the environment may be more supportive.
Finding maintainers can be a bit harder. Again, the MAINTAINERS file is
the place to start. That file tends to not always be up to date, though,
and not all subsystems are represented there. The person listed in the
MAINTAINERS file may, in fact, not be the person who is actually acting in
that role currently. So, when there is doubt about who to contact, a
useful trick is to use git (and "git log" in particular) to see who is
currently active within the subsystem of interest. Look at who is writing
patches, and who, if anybody, is attaching Signed-off-by lines to those
patches. Those are the people who will be best placed to help with a new
development project.
The task of finding the right maintainer is sometimes challenging enough
that the kernel developers have added a script to ease the process:
::
.../scripts/get_maintainer.pl
This script will return the current maintainer(s) for a given file or
directory when given the "-f" option. If passed a patch on the
command line, it will list the maintainers who should probably receive
copies of the patch. This is the preferred way (unlike "-f" option) to get the
list of people to Cc for your patches. There are a number of options
regulating how hard get_maintainer.pl will search for maintainers; please be
careful about using the more aggressive options as you may end up including
developers who have no real interest in the code you are modifying.
If all else fails, talking to Andrew Morton can be an effective way to
track down a maintainer for a specific piece of code.
When to post?
-------------
If possible, posting your plans during the early stages can only be
helpful. Describe the problem being solved and any plans that have been
made on how the implementation will be done. Any information you can
provide can help the development community provide useful input on the
project.
One discouraging thing which can happen at this stage is not a hostile
reaction, but, instead, little or no reaction at all. The sad truth of the
matter is (1) kernel developers tend to be busy, (2) there is no shortage
of people with grand plans and little code (or even prospect of code) to
back them up, and (3) nobody is obligated to review or comment on ideas
posted by others. Beyond that, high-level designs often hide problems
which are only revealed when somebody actually tries to implement those
designs; for that reason, kernel developers would rather see the code.
If a request-for-comments posting yields little in the way of comments, do
not assume that it means there is no interest in the project.
Unfortunately, you also cannot assume that there are no problems with your
idea. The best thing to do in this situation is to proceed, keeping the
community informed as you go.
Getting official buy-in
-----------------------
If your work is being done in a corporate environment - as most Linux
kernel work is - you must, obviously, have permission from suitably
empowered managers before you can post your company's plans or code to a
public mailing list. The posting of code which has not been cleared for
release under a GPL-compatible license can be especially problematic; the
sooner that a company's management and legal staff can agree on the posting
of a kernel development project, the better off everybody involved will be.
Some readers may be thinking at this point that their kernel work is
intended to support a product which does not yet have an officially
acknowledged existence. Revealing their employer's plans on a public
mailing list may not be a viable option. In cases like this, it is worth
considering whether the secrecy is really necessary; there is often no real
need to keep development plans behind closed doors.
That said, there are also cases where a company legitimately cannot
disclose its plans early in the development process. Companies with
experienced kernel developers may choose to proceed in an open-loop manner
on the assumption that they will be able to avoid serious integration
problems later. For companies without that sort of in-house expertise, the
best option is often to hire an outside developer to review the plans under
a non-disclosure agreement. The Linux Foundation operates an NDA program
designed to help with this sort of situation; more information can be found
at:
https://www.linuxfoundation.org/nda/
This kind of review is often enough to avoid serious problems later on
without requiring public disclosure of the project.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
첫 code 전에 문제와 community를 확인하기
1-10Kernel 개발 project를 생각하면 바로 code를 쓰고 싶지만 성공에 필요한 기반은 첫 줄을 작성하기 전에 만드는 편이 좋다. 초기 planning과 communication에 시간을 쓰면 이후 훨씬 많은 시간을 절약할 수 있다.
문제와 제안한 해결책을 구분하기
13-20성공적인 kernel 개선은 해결할 문제를 명확히 설명하는 데서 시작한다. 특정 hardware driver처럼 문제가 분명한 경우도 있지만 제안한 solution을 실제 problem과 혼동하면 어려움이 생긴다.
Audio latency와 LSM module 사례
22-56과거 Linux audio developer는 excessive latency로 생기는 dropout을 막으려고 특정 application에 realtime scheduler 접근을 주는 LSM hook 기반 kernel module을 만들었다. Linux-kernel mailing list에 제출하자 즉시 반대에 부딪혔다.
Audio developer에게 module은 당장 문제를 해결했지만 kernel community는 원래 없던 privilege를 process에 부여하는 방식이 LSM 오용이며 system stability 위험이라고 보았다. Community는 단기적으로 rlimit을 통한 realtime scheduling access, 장기적으로 kernel latency 감소 작업을 선호했다.
Audio 측은 이미 구현한 solution을 넘어 대안을 받아들이지 못했고 kernel 개발 절차에 환멸을 느꼈다. 원문은 한 developer가 kernel developer를 비난한 인용을 https://lwn.net/Articles/131776/ 에서 소개한다.
실제로 kernel developer는 특정 module보다 system stability, 장기 maintenance, 문제에 맞는 올바른 solution에 관심이 있었다. 교훈은 code에 투자하기 전에 특정 해법이 아니라 문제 자체에 집중하고 community와 논의하라는 것이다.
Project 시작 전에 답할 세 질문
58-68- 정확히 어떤 문제를 해결해야 하는가?
- 누가 이 문제의 영향을 받고 solution은 어떤 use case를 다뤄야 하는가?
- 현재 kernel은 이 문제를 해결하는 데 어떤 점이 부족한가?
이 질문에 답한 뒤에야 가능한 solution을 검토할 의미가 있다.
구현 전 discussion이 절약하는 비용
71-93- Kernel이 이미 예상하지 못한 방식으로 문제를 해결하고 있을 수 있다. Linux는 크고 문서화가 완전하지 않아 기존 기능을 놓치기 쉽다. 기존 driver와 같은 기능을 다시 구현한 새 driver는 낭비이며 mainline에 accept되지 않는다.
- 제안한 solution 일부가 mainline merge 기준에 맞지 않을 수 있다. Code를 쓰기 전에 아는 것이 낫다.
- 다른 developer가 같은 문제를 고민해 더 나은 idea를 갖고 있거나 구현을 도울 수 있다.
닫힌 개발 뒤 늦게 드러난 통합 문제
95-122Community와 격리된 채 설계하고 개발한 kernel code는 공개 뒤에야 문제가 드러나는 경우가 많다. 심하면 community 기준에 맞추는 데 수개월 또는 수년이 걸린다.
- Devicescape network stack은 UP system만 가정해 설계되었다. SMP locking을 뒤늦게 추가하는 어려움 때문에 mac80211로 mainline에 merge되기까지 1년 넘게 지연되었다.
- Reiser4는 core developer가 VFS layer에 있어야 한다고 본 기능과 user가 유발할 수 있는 deadlock 위험을 포함했다. 문제가 늦게 드러났고 일부 수정이 거부되어 mainline 밖에 남았다.
- AppArmor는 internal VFS data structure를 안전하지 않고 신뢰하기 어려운 방식으로 사용했다. 이 문제를 포함한 여러 우려로 mainline 포함이 수년 지연되었다.
세 사례 모두 kernel developer와 일찍 논의했다면 큰 고통과 추가 작업을 줄일 수 있었다.
Mailing list와 maintainer 찾기
125-164계획을 공개할 때는 관련 mailing list와 maintainer를 찾는다. MAINTAINERS file에서 적합한 subsystem list를 찾고, 가능하면 일반 linux-kernel보다 해당 list에 게시해 전문성을 가진 developer에게 도달한다.
MAINTAINERS가 오래되었거나 subsystem이 누락되고 명시된 사람이 실제 역할을 하지 않을 수 있다. 의심스러우면 git log로 최근 patch author와 Signed-off-by를 붙이는 사람을 찾아 현재 활동 중인 maintainer를 확인한다.
scripts/get_maintainer.pl-f option은 file 또는 directory maintainer를 찾고 patch file을 넘기면 Cc해야 할 사람을 나열한다. Patch 자체를 입력하는 방식이 -f보다 권장된다. Aggressive search option은 실제 관심이 없는 developer까지 포함할 수 있으므로 주의한다. 다른 방법이 모두 실패하면 문서 작성 당시에는 Andrew Morton에게 문의해 maintainer를 찾을 수 있었다.
계획을 게시할 시점과 무응답 해석
167-189가능하면 초기 단계에 해결할 문제와 구현 계획을 게시한다. 정보가 많을수록 community가 유용한 의견을 주기 쉽다.
적대적 반응보다 아무 반응도 없는 상황이 생길 수 있다. Kernel developer는 바쁘고 실현 code가 없는 큰 계획도 많으며 누구도 타인의 idea를 review할 의무가 없다. High-level design은 구현할 때만 보이는 문제를 숨기므로 developer가 실제 code를 선호하기도 한다.
RFC에 comment가 없다고 관심이 없거나 문제가 없다고 단정할 수 없다. 이때는 작업을 진행하되 과정에서 community에 계속 알린다.
회사 승인과 비공개 review
192-223회사 환경에서 개발한다면 계획이나 code를 public list에 게시할 권한을 적절한 manager에게 받아야 한다. GPL-compatible license로 release 승인을 받지 않은 code를 게시하면 특히 문제가 되므로 management와 legal team이 이른 시점에 합의해야 한다.
아직 공개되지 않은 제품을 지원하는 작업은 employer 계획을 public list에 밝히기 어려울 수 있다. 먼저 secrecy가 정말 필요한지 검토한다.
실제로 조기 공개가 불가능하고 사내 경험 많은 kernel developer도 없다면 외부 developer와 NDA를 맺고 계획을 검토받는 방법이 있다. Linux Foundation은 https://www.linuxfoundation.org/nda/ 의 NDA program을 제공한다. 이런 비공개 review만으로도 project를 공개하지 않으면서 큰 통합 문제를 예방할 수 있다.
첫 code를 쓰기 전에 할 일
3.Early-stage.rst:3-11Linux 커널 project를 떠올리면 바로 coding을 시작하고 싶어지지만, 중요한 project일수록 성공에 필요한 기반은 첫 줄을 쓰기 전에 마련된다. 초기 계획과 communication에 쓴 시간은 뒤의 재설계와 통합 문제에 드는 더 큰 시간을 줄인다.