안녕하세요? 허니데이즈입니다. 오늘은 지르콘 커널 개발에 기여하는 방법에 대해 알려드리도록 하겠습니다.



 지르콘에 패치(프로그램 수정) 기여하기
현재 지르콘 개발을 위해 많은 개발자들이 활발하게 활동하고 있으며, 새로운 기능보다는 작은 버그 수정을 통해 기여할 수 있다. 때문에 지르콘 개발을 위한 Process, Style, Documentation 등 3가지 지침(2018.08.02)이 있다.

 

 Process

1. GitHub에서 프로그램 패치 요청이 허용되지 않는다. 패치는 Gerrit Code Review를 통해서만 처리된다.

 https://fuchsia-review.googlesource.com/#/q/project:zircon

2. freenode irc Network의 #fuchsia 채널은 질의문탑하기 좋다.

3. 커밋 주제에 [tags]를 포함하면 모듈, 라이브러리, 앱 등이 변경의 영향을 받는다. 여기 스타일은 다소 비형식적으로 진행된다. 과거 변경사항을 살펴보고 이 변경사항이 어떻게 사용되는지 확인해야 한다. Gerrit Needs Label: Commit-Message-has-tags가 누락된 경우 변경사항을 플래그로 표시된다.

4. Test: <how this was tested> 커밋 메시지와 같은 라인을 포함하거나 그렇지 않으면 Gerrit가 변경 내용을 Needs Label: Commit-Message-has-TEST-line 플래그로 표시한다.

5. 전체 (Java 스타일) 정규 표현식은 (?i:test|tests|tested|testing)[ \t]*[=:] 이므로 TESTED=asdf 또는Testing : 1234 같은 행이 유효하며 Test: 만을 포함하는 행과 함께 다음 행의 세부 사항이 포함된다
6. [Googler 전용] 일반적으로 메시지는 문제 ID를 참조 할 수 있으며, 이 ID는 Gerrit UI에서 링크로 바뀌게 된다. 또한 문제는 BUG-123 #done 구문을 사용하여 자동으로 닫을 수 있다. 참고로 지르콘의 이슈 트래커는 현재 외부 참여자에게는 공개되지 않았다.

7. 지르콘은 모든 주요 타겟 (x86-64, arm64)을 변경할 때마다 빌드 가능해야 한다. ./scripts/build-all-zircon이 도움이 될 수 있다.

8. 단위 테스트를 위반하면 안된다. Zircon을 부팅하고 "runtests"를 실행하여 모두 통과하는지 확인해야 한다.

9. 공백(Whitespace)이나 스타일 변경을 피해야 한다.

10. 가능한 경우, 여러 모듈을 한꺼번에 변경하는 변경을 피해야 한다. 대부분의 변경사항은 단일 라이브러리, 드라이버, 앱 등으로 변경해야 한다.

 

 Style

코드 스타일은 대부분 다음을 제외하고 Google C++ 스타일 가이드를 따르면 된다.

1. 기존 코드를 편집할 때 로컬 스타일과 일치해야 한다. 이눈 다른 스타일 규칙보다 우선 시 된다.

2. 최대 라인 너비는 80 보다는 100자로 한다.

3. 들여쓰기는 두 개가 아닌 네 개의 공백이다. 탭은 사용하지 않으며 라인에 뒤 공백을 만들지 않는다. Gerrit는 diff에서 빨간색 배경을 사용하여 잘못된 공백 사용을 표시한다.

4. 지르콘은 포인터 선언 char* p로 표현한다. char *p로 표현하지 않는다. 지르콘은 asterisk-with-name 대신 asterisk-with-type으로 표준화 하였다.

switch 문에서 case 레이블은 들여 쓰지 않아야 한다.

 void foo(int which) {
    switch (which) {
    case 0:
        foo_zero();
        break;
    case 17:
        foo_seventeen();
        break;
    default:
        panic("I don't know how to foo here (which = %d)\n", which);
    }
}

5. Put curly braces around the body of any loop and in any if statement where the body is on another line (including any if statement that has an else if or else part). 다음과 같이 쓸수 있다.

 if (result! = ZX_OK) return result;

다음과 같이 작성하지 않아야 한다.

if (result == ZX_OK)
    return do_more_stuff(data);
else
    return result;

다음과 같이 작성하지 않아야 한다.

while (result == ZX_OK)
    result = do_another_step(data);  

이 규칙에 의해 시행되지 않으므로 clang-fmt 코드 작성이나 커밋 검토시 주의해야 한다.

6. ./scripts/clang-fmt 파일을 다시 포맷 하려면 실행할 수 있다 . 인수로 파일 이름을 전달하면 된다.

 scripts/clang-fmt kernel/top/main.c kernel/top/init.c

clang-fmt 스크립트가 자동으로 다운로드하고 clang-format 바이너리를 실행한다. 라인 길이를 제외하고 대부분의 스타일 문제 clang-format가 수정된다.

 

 

 Documentation

문서는 Markdown 파일에 있어야 한다. Google의 Markdown은 main repo browser의 Gitiles와 the mirrored repo의 Github에서 렌더링된다. 두 웹사이트에서 문서가 어떻게 렌더링되는지 확인해야 한다. 몇 가지 주목할만한 문서는 docs/syscalls.md에 syscall 목록이 있고, docs/kernel_cmdline.md에 커널 cmdline 옵션 목록이 있다. syscalls 또는 cmdlines를 편집하거나 추가할 때 문서를 업데이트 해야 한다! h2md 도구는 소스 파일을 뽑아 내장된 Markdown을 추출 할 수 있다. 현재는 DDK용 API 문서를 생성하는데 사용되고 있다. ./scripts/make-markdown 에는 system/ 트리의 모든 소스 파일에 대해 h2md를 실행한다.

 

출처: https://fuchsia.googlesource.com/zircon/+/master/docs/contributing.md

 

지르콘 커널에 대해 더 알고 싶으시다면 아래 목차에서 클릭! 

지르콘 커널이란?

Zircon

지르콘 커널 개발 환경 구축하기

Getting Started

지르콘 커널 개발에 기여하는 방법

Contributing Patches

지르콘 커널의 개념 알기

Concepts Overview

지르콘 커널 구성요소(Kernel Objects)는?

Kernel Objects

지르콘 커널에서 사용되는 프로세스(Process)란?

Process Objects

지르콘 커널에서 사용되는 쓰레드(Thread)란?

Thread Objects

지르콘 커널에서 사용되는 핸들(Handles)이란?

Handles

지르콘 커널의 시스템콜하는 방식은?

System Calls

지르콘 커널의 드라이버 개발 키트 사용하는 방법 - 장치 모델

Driver Development Kit

지르콘 커널의 드라이버 개발 키트 사용하는 방법 - 장치 프로토콜

지르콘 커널의 드라이버 개발 키트 사용하는 방법 - 지르콘 드라이버 개발

지르콘 커널의 드라이버 개발 키트 사용하는 방법 - 플랫폼 버스

지르콘 커널의 드라이버 개발 키트 사용하는 방법 - 장치 펌웨어

지르콘 커널을 시험하는 방법은?

Testing

지르콘 커널의 취약점은 무엇일까?

Hacking notes

지르콘 커널의 메모리와 자원 사용은 어떻게 할까?

Memory usage analysis tools

지르콘 커널과 LK(Little Kernel)의 관계는?

Relationship with LK

지르콘 커널을 위한 마이크로 벤츠마크는?

Micro-benchmarks


+ Recent posts