리눅스 커널은 어떻게 테스트됩니까?

Linux 커널 개발자는 코드를 로컬에서 그리고 커밋 한 후에 어떻게 테스트합니까? 그들은 일종의 단위 테스트, 빌드 자동화를 사용합니까? 테스트 계획?

리눅스 커널은 커뮤니티 테스트에 중점을두고 있습니다.

일반적으로 모든 개발자는 제출하기 전에 자체 코드를 테스트하며, Linus의 커널 개발 버전 또는 작업과 관련된 프로젝트를 위해 다른 불안정한 / 개발 트리 중 하나를 사용하는 경우가 많습니다. 이것은 그들이 종종 그들의 변화와 다른 사람들의 변화를 테스트한다는 것을 의미합니다.

공식적인 테스트 계획에는 그다지 많은 경향이 없지만 기능이 업스트림 트리에 병합되기 전에 추가 테스트가 필요할 수 있습니다.

Dean이 지적했듯이 자동 테스트, Linux 테스트 프로젝트 및 커널 자동 테스트 ( 좋은 개요 )도 있습니다.

개발자는 종종 변경 사항을 테스트하기 위해 자동화 된 테스트를 작성하지만 이러한 임시 테스트를 중앙에서 수집하는 메커니즘이 있는지 잘 모르겠습니다.

커널의 어떤 영역이 변경되는지에 따라 달라집니다. 새로운 네트워크 드라이버에 대해 수행하는 테스트는 코어 스케줄링 알고리즘을 대체 할 때 수행하는 테스트와는 상당히 다릅니다.

당연히 커널 자체와 그 부분은 릴리스 전에 테스트되지만 이러한 테스트는 기본 기능 만 다룹니다. Linux 커널 테스트를 수행하는 몇 가지 테스트 시스템이 있습니다.

Linux Test Project (LTP) 는 Linux의 안정성과 안정성을 검증하는 테스트 스위트를 오픈 소스 커뮤니티에 제공합니다. LTP 테스트 스위트에는 Linux 커널 및 관련 기능을 테스트하기위한 도구 모음이 포함되어 있습니다. https://github.com/linux-test-project/ltp

자동 측정 - 완전 자동화 된 테스트 프레임 워크. 주로 Linux 커널을 테스트하도록 설계되었지만 Linux 플랫폼에서 새 하드웨어 검증, 가상화 테스트 및 기타 일반 사용자 공간 프로그램 테스트와 같은 여러 다른 목적에 유용합니다. GPL 하의 오픈 소스 프로젝트이며 Google, IBM, Red Hat 등을 포함한 여러 조직에서 사용 및 개발합니다. http://autotest.github.io/

또한 몇몇 주요 GNU / Linux 배포 회사가 개발 한 인증 시스템이 있습니다. 이러한 시스템은 일반적으로 하드웨어와의 호환성을 위해 완전한 GNU / Linux 배포판을 확인합니다. Novell, Red Hat, Oracle, Canonical, Google에서 개발 한 인증 시스템이 있습니다 .

리눅스 커널의 동적 분석을위한 시스템도 있습니다 :

Kmemleak 은 Linux 커널에 포함 된 메모리 누수 탐지기입니다. 고아 개체가 해제되지 않고 / sys / kernel / debug / kmemleak을 통해서만보고된다는 차이점을 가지고 추적 가비지 수집기와 유사한 방식으로 가능한 커널 메모리 누수를 감지하는 방법을 제공합니다.

Kmemcheck 는 동적으로 할당 된 모든 읽기 및 쓰기 메모리를 트래핑합니다 (예 : kmalloc ()). 이전에 기록되지 않은 메모리 주소를 읽으면 커널 로그에 메시지가 인쇄됩니다. 또한 리눅스 커널의 일부입니다

Fault Injection Framework (Linux 커널에 포함)를 사용하면 오류와 예외를 응용 프로그램의 논리에 주입하여 시스템의 적용 범위와 내결함성을 높일 수 있습니다.

Linux 커널 개발자는 코드를 로컬에서 그리고 커밋 한 후에 어떻게 테스트합니까?

그들은 일종의 단위 테스트, 빌드 자동화를 사용합니까?

고전적인 의미에서 아닙니다.

예 : Ingo Molnar는 다음과 같은 워크로드를 실행합니다. 1. 임의의 구성 옵션 세트로 새 커널을 빌드합니다. 2. 부팅합니다. 3. goto 1

모든 빌드 실패, 부팅 실패, BUG 또는 런타임 경고가 처리됩니다. 24/7. 여러 상자를 곱하면 많은 문제를 발견 할 수 있습니다.

테스트 계획?

아니.

중앙 테스트 시설이 있다는 오해가있을 수 있습니다. 누구나 그가 원하는 것을합니다.

인트 리 툴

커널에서 테스트 도구를 찾는 좋은 방법은 다음과 같습니다.

• make help 모든 목표를 읽고
• 아래보기 도구 / 테스트

v4.0에서는 다음과 같이 나옵니다.

• 도구 / 테스트 / 자기 테스트 에서 kselftest . 로 실행하십시오 make kselftest. 이미 빌드 된 커널을 실행 중이어야합니다. 참고 : Documentation / kselftest.txt , https://kselftest.wiki.kernel.org/

• ktest 에서 도구 / 테스트 / ktest . 참조 : http://elinux.org/Ktest , http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest

• 의 정적 분석기 섹션 make help에는 다음과 같은 대상이 포함되어 있습니다.

  • checkstack: Perl : 리눅스 소스에서 checkstack.pl은 무엇을 하는가?
  • coccicheckCoccinelle의 경우 ( askb로 언급 )

커널 CI

https://kernelci.org/ 는 커널 테스트를보다 자동화되고 가시적으로 만드는 것을 목표로하는 프로젝트입니다.

빌드 및 부팅 테스트 만 수행하는 것으로 보입니다 (TODO 부팅 작업을 자동으로 테스트하는 방법은 https://github.com/kernelci/ 이어야 함 ).

Linaro 는 많은 대기업의 기여로 프로젝트의 주요 관리자 인 것 같습니다 : https://kernelci.org/sponsors/

리나로 용암

http://www.linaro.org/initiatives/lava/ 는 개발 보드 가동 및 Linux 커널에 중점을 둔 CI 시스템처럼 보입니다.

팔 리사

https://github.com/ARM-software/lisa

그것이 무엇을하는지 확실하지 않지만 ARM과 Apache Licensed에 의한 것이므로 살펴볼 가치가 있습니다.

데모 : https://www.youtube.com/watch?v=yXZzzUEngiU

단계 디버거

실제로 단위 테스트는 아니지만 테스트가 실패하면 도움이 될 수 있습니다.

• QEMU + GDB : https://stackoverflow.com/a/42316607/895245
• KGDB : https://stackoverflow.com/a/44226360/895245

내 자신의 QEMU + Buildroot + Python 설정

나는 또한 셋업 개발의 용이성에 초점을 시작,하지만 난뿐만 아니라 거기에 기능 테스트를 몇 가지 간단한 추가 결국 : https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b3141724#test-this -레포

다른 모든 설정을 자세하게 분석하지는 않았지만 실제로 설정보다 훨씬 많은 작업을 수행 할 가능성이 있지만 문서 및 자동화 기능이 많기 때문에 설정을 빠르게 시작할 수 있다고 생각합니다.

커널 테스트를 자동화하는 것은 쉽지 않습니다. 대부분의 Linux 개발자는 adobriyan이 언급 한 것처럼 자체적으로 테스트를 수행합니다.

그러나 Linux 커널 디버깅에 도움이되는 몇 가지 사항이 있습니다.

• kexec : BIOS로 돌아 가지 않고 다른 커널을 메모리에 넣고 재부팅 할 수있는 시스템 호출. 실패하면 재부팅합니다.
• dmesg : 확실히 커널 부팅 중에 발생한 것과 그것이 작동 / 작동하지 않는지에 대한 정보를 찾을 수있는 곳.
• 커널 인스 트루먼 테이션 : printk (및 커널 출력 내용을 확인할 수있는 'CONFIG_PRINTK_TIME'옵션 외에도 커널 구성을 사용하면 트레이서를 추적하여 많은 항목을 디버깅 할 수 있음) 이 일어나고있다.

그런 다음 개발자는 일반적으로 다른 사람들이 자신의 패치를 검토하도록합니다. 패치를 로컬에서 검토하고 다른 사항을 방해하지 않는 것으로 보이면 패치가 Linus의 최신 커널에서 작동하도록 테스트하여 아무 것도 깨지 않고 패치를 업스트림으로 푸시합니다.

편집 : 다음 은 패치가 커널에 통합되기 전에 패치가 진행되는 과정을 자세히 보여주는 멋진 비디오 입니다.

Linux 커널의 기능 테스트, 하드웨어 인증 테스트 및 성능 테스트에 중점을 둔 위 / 아래 사항 외에도.

실제로 스크립트, 정적 코드 분석 도구, 코드 검토 등 많은 테스트가 실제로 발생하며, 버그를 잡는 데 매우 효율적입니다. 그렇지 않으면 응용 프로그램에서 문제가 발생할 수 있습니다.

스파 스 – Linux 커널에서 결함을 찾도록 설계된 오픈 소스 도구입니다.

Coccinelle 은 C 코드에서 원하는 일치 및 변환을 지정하기위한 언어 SmPL (Semantic Patch Language)을 제공하는 일치 및 변환 엔진을 수행하는 또 다른 프로그램입니다.

checkpatch.pl 및 기타 스크립트 -코딩 스타일 문제는 커널 소스 트리의 Documentation / CodingStyle 파일에서 찾을 수 있습니다. 읽을 때 기억해야 할 중요한 점은이 스타일이 다른 스타일보다 우수하다는 것이 아니라 일관성이 있다는 것입니다. 이를 통해 개발자는 커널 소스 트리의 scripts / checkpatch.pl이 개발 된 코딩 스타일 문제를 쉽게 찾아 수정할 수 있습니다. 이 스크립트는 문제를 쉽게 지적 할 수 있으며 검토자가 나중에 문제를 지적하여 시간을 낭비하는 대신 개발자가 변경 사항에 대해 항상 실행해야합니다.

QEMU, VirtualBox 또는 Xen과 같은 빠른 테스트를 수행하기 위해 가상화를 사용하고 구성 및 자동화 된 테스트를 수행하는 일부 스크립트를 상상합니다.

자동화 된 테스트는 많은 임의의 구성 또는 몇 가지 특정 구성 (특정 문제로 작업하는 경우)을 시도하여 수행 할 수 있습니다. 리눅스에는 커널에서 디버그 데이터를 모니터링하고 기록하기위한 많은 저수준 도구 (예 : dmesg)가 있으므로이 도구도 사용된다고 생각합니다.

또한 있습니다 :

결과를 분석하기위한 벤치 마크 및 스크립트 모음 인 MMTests

https://github.com/gormanm/mmtests

Linux 시스템 콜 퍼즈 테스터 인 Trinity

http://codemonkey.org.uk/projects/trinity/

또한 sourceforge 의 LTP 페이지는 상당히 구식이며 프로젝트는 GitHub https://github.com/linux-test-project/ltp 로 이동했습니다.

내가 아는 한, 인텔이 자동으로 성능 회귀 검사 도구 (이름 lkp / 0 day)를 실행 / 펀딩하고 있으며, 메일 링리스트로 전송 된 각 유효한 패치를 테스트하고 hackbench와 같은 다른 마이크로 벤치 마크에서 변경된 점수를 확인합니다 , fio, unixbench, netperf 등. 성능 회귀 / 개선이 이루어지면 해당 보고서가 패치 작성자 및 Cc 관련 관리자에게 직접 전송됩니다.

LTP 및 Memtest는 일반적으로 선호되는 도구입니다.

adobriyan은 Ingo의 랜덤 구성 빌드 테스트 루프를 언급했습니다. 그것은 거의 0 일 테스트 봇 (일명 kbuild 테스트 봇)으로 덮여 있습니다. 인프라에 대한 좋은 기사는 다음과 같습니다. Kernel Build / boot testing

이 설정의 기본 개념은 개발자에게 최대한 빨리 오류를 바로 잡을 수 있도록 개발자에게 알리는 것입니다. (kbuild 인프라가 관리자의 서브 시스템 트리를 테스트하기 때문에 패치가 Linus의 트리로 패치되기 전에)

나는 리눅스 커널 컴파일을하고 리눅스 버전 3을 사용하는 android (Marshmallow and Nougat)에 대한 일부 수정을 수행했다. 나는 리눅스 시스템에서 크로스 컴파일하고 수동으로 오류를 디버깅 한 다음 안드로이드에서 부팅 이미지 파일을 실행하고 확인한다. 그것은 허점으로 가고 있었다. 완벽하게 실행되면 시스템 요구 사항에 따라 완벽하게 컴파일됩니다.
MotoG 커널 컴파일

참고 : -Linux 커널은 시스템 하드웨어에 따른 요구 사항에 따라 변경됩니다

기여자가 패치 파일을 제출 한 후 및 병합 요청을 한 후 Linux 게이트 키퍼는 패치를 통합 및 검토하여 패치를 확인하고, 성공하면 패치를 관련 지점에 병합하고 새 버전을 릴리스합니다. Linux Test Project ( https://github.com/linux-test-project/ltp )는 패치를 적용한 후 커널에 대해 테스트 시나리오 (Test Cases)를 실행하는 주요 소스입니다. 약 2 ~ 4 시간이 소요될 수 있습니다. 선택한 커널의 파일 시스템에 대해 테스트 할 예정입니다. Ex : Ext4는 EXT3 등에 대해 다른 결과를 생성합니다.

커널 테스트 절차.

1. 저장소에서 최신 커널 소스를 가져 오십시오 ( https://www.kernel.org/ 또는 Github.com)
2. 패치 파일 적용 (Diff 도구 사용)
3. 새로운 커널을 빌드하십시오.
4. LTP의 테스트 절차에 대한 테스트 ( https://github.com/linux-test-project/ltp )