Linux 드라이버를 일정 단계까지 개발하면kernel에.org 제출 코드는 좋은 선택입니다.상류에 코드를 제출하지 않은 개발자들에게는 아직도 해결해야 할 의문이 많다.예를 들어, 도대체 우리는 어디에 드라이버를 제출합니까?제출할 때 우리의 코드는 어떤 상태에 있어야 합니까?제출하는 과정은 어떻습니까?

제출 위치

Linux staging tree는 Greg KH에서 만든 드라이버 커밋을 위한git 저장소입니다.우리는 Staging tree를 코드가mainline 핵에 들어가기 전의 예과반으로 볼 수 있으며, 새로 추가된 드라이버는 우선 지역 사회의 리뷰와 테스트를 위해 여기에 두어야 한다.Staging tree는 Greg KH가 2008년에 구축한kernel tree로 충분한 테스트를 하지 않았거나 다른 이유로 커널에 들어가지 못한 새로운 드라이버와 파일 시스템을 설치하는 데 목적을 둔다.
Linux staging tree의 URL은 "git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6.git"아니면"http://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6.git"git 프로토콜의 포트 번호는 9418입니다. 많은 회사의 방화벽은 80포트만 개방하기 때문에 clone 코드 창고에서 git 프로토콜이 시간을 초과하면 http 프로토콜을 시도해 보세요.
Linux staging tree에 대한 더 상세한 설명은 저의 앞의 블로그인 을 참고할 수 있습니다.

우리 코드

드라이버를 상류에 제출하기 전에, 코드가 리눅스 핵의 coding 스타일을 따를 수 있도록 보장해야 합니다.물론 이 규정은 강제적인 것이 아닙니다. 리눅스 커널 코드를 자주 읽으면 커널 코드 스타일에 대한 드라이버의 준수 상황도 좋지 않다는 것을 알 수 있습니다.그러나 일치된 코드 스타일은 코드 유지보수에 큰 도움이 되기 때문에 리눅스 내장 드라이버인 우리에게 코드 스타일을 따르는 것은 좋은 습관이다.리눅스 커널의 코드 스타일에 대한 상세한 정보는 리눅스 커널의 Documentation/Coding Style 문서나 저의 이전 블로그인 을 참고하십시오.
드라이버를 제출하기 전에 정적 코드 검사 도구sparse로 코드를 검사해야 합니다.
sparse의 소스 코드는 "git://git.kernel.org/pub/scm/devel/sparse/sparse.git'코드를 얻은 후'make;make install'을 실행하여 실행 가능한 프로그램을 컴파일합니다.기본적으로 sparse 프로그램은 디렉터리 '~/bin' 아래에 놓여 있습니다. 이 위치가 마음에 들지 않으면 Makefile을 수정해서 경로를 설정할 수 있습니다.주의해야 할 것은sparse를 사용하기 전에 PATH 환경 변수를 정확하게 설정해야 한다는 것이다.
sparse의 사용 방법은 간단합니다. make 드라이버에 'C=N' 옵션을 추가하면 됩니다. 그 중에서 N의 수치는 1 또는 2입니다.N=1은 다시 컴파일해야 하는 C 파일에 대해 코드 검사를 하고, N=2는 모든 C 파일에 대해 코드 검사를 한다는 뜻이다.
Staging 디렉터리의 드라이브에 대해 말하자면, 우리는 미래의 유지보수 계획을 설명하기 위해 TODO 파일을 첨부해야 한다.일반적으로 TODO 파일은 다음과 같이 쓸 수 있습니다.
TODO:
- support more features
- use kernel coding style
- checkpatch.pl fixes

제출 방법

패치 형식으로 드라이버를 Staging tree에 제출할 수 있습니다.제출하기 전에 Staging tree clone을 로컬로 가져온 다음 현재 작업 디렉터리를 기반으로 patch를 만들어야 합니다.
Git는 다음 명령을 사용하여 서식 적용 패치를 만들 수 있습니다.
git format-patch -N
그 중에서, N은 정수입니다. 가장 최근의 N회 제출을 N개의 patch로 지정하는 데 사용됩니다.예를 들어 N=1일 때 가장 최근의 제출을 패치로 만든다는 뜻이다.Git는 제출한 로그 정보에 따라 patch 파일의 이름을 자동으로 지정합니다.
여기에 주의해야 할 것은 매번 제출한log의 설명은 일정한 격식에 따라야 한다는 것이다.
Log의 첫 번째 행은 간단한 설명입니다.본고는 주로 Staging tree에 코드를 제출하는 방법을 소개하는데, 우리는 Log의 첫 줄에서 "Staging:"로 시작해야 한다.Log의 마지막 줄은 제출자의 이메일 정보를 제공해야 합니다. "Signed-off-by: wwang ”.
예를 들어, 우리의 Staging driver가 Hello 라고 명명된다고 가정하자.world,log의 형식은 다음과 같습니다.
staging: hello_world: My first commit
This is my first commit.
Signed-off-by: wwang
Patch가 생성된 후에 Staging tree 관리자에게 보내야 합니다. 보통 Greg KH 본인과 linux 호스트가 움직이는 개발자 목록입니다.이 절차도git를 사용하여 우리가 완성하는 것을 도울 수 있지만, 우선 시스템에 msmtp와git-email 두 가방이 설치되어 있는지 확인해야 한다.메일 서버가 Exchange라면 NTLM 인증이 필요할 수도 있습니다. 이것은 msmtp가 NTLM을 지원하도록 요구합니다.Ubuntu 창고의 msmtp는 기본적으로 NTLM을 지원하기 때문에 직접 사용할 수 있지만, 일부 다른 버전의 소프트웨어 창고에서 자체로 가지고 있는 msmtp는 NTLM(예를 들어 Arch Linux)을 지원하지 않기 때문에 이런 상황은 스스로 컴파일해야 한다.
msmtp를 설치한 후 "~/. msmtprc"파일을 설정해야 합니다.Gmail의 경우.msmtprc를 이렇게 구성할 수 있습니다.

# Set default values for all following accounts.
defaults
logfile ~/.msmtp.log

# gmail
account gmail
protocol smtp
host smtp.gmail.com
from [email protected]
user [email protected]
password mypasswd
port 587
auth on
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
syslog LOG_MAIL 

# Set a default account
account default : gmail

git를 사용하여 patch를 보내는 명령은 다음과 같습니다.
git send-email  \  
　　--smtp-server/usr/bin/msmtp  \ 
　　--from [email protected]  \
　　--to [email protected]  \  
　　--to [email protected]  \  
　　--to [email protected]  \  
　　./my.patch
patch를 보내는 것은 드라이버를 제출하는 첫걸음일 뿐이고, 이후에는 끊임없는 유지보수와 보완이 필요하다. 코드를 내부 핵에 버리고 손을 놓는 것은 바람직하지 않다.제출 코드의 또 다른 원칙은 매번 제출할 때마다 한 가지 일만 해야 내부 관리자가 우리의 코드를 리뷰하는 데 비교적 편리하다는 것이다.