Nhân Linux được kiểm tra như thế nào?

Làm thế nào để các nhà phát triển nhân Linux kiểm tra mã của họ cục bộ và sau khi họ đã cam kết? Họ có sử dụng một số loại thử nghiệm đơn vị, xây dựng tự động hóa? kế hoạch kiểm tra?

Hạt nhân linux tập trung vào kiểm tra cộng đồng.

Thông thường, bất kỳ nhà phát triển nào cũng sẽ kiểm tra mã của riêng họ trước khi gửi và thông thường họ sẽ sử dụng phiên bản phát triển của kernel từ Linus hoặc một trong những cây phát triển / không ổn định khác cho dự án liên quan đến công việc của họ. Điều này có nghĩa là họ thường kiểm tra cả thay đổi của họ và thay đổi của người khác.

Có xu hướng không có nhiều trong cách lập kế hoạch kiểm tra chính thức, nhưng thử nghiệm bổ sung có thể được yêu cầu trước khi các tính năng được hợp nhất vào cây ngược dòng.

Như Dean đã chỉ ra, cũng có một số thử nghiệm tự động, dự án thử nghiệm linux và autotest kernel ( tổng quan tốt ).

Các nhà phát triển cũng thường sẽ viết các bài kiểm tra tự động được nhắm mục tiêu để kiểm tra sự thay đổi của họ, nhưng tôi không chắc có cơ chế (thường được sử dụng) để thu thập tập trung các bài kiểm tra adhoc này.

Tất nhiên, nó phụ thuộc rất nhiều vào khu vực của hạt nhân đang được thay đổi - thử nghiệm mà bạn thực hiện đối với trình điều khiển mạng mới hoàn toàn khác với thử nghiệm bạn thực hiện khi thay thế thuật toán lập lịch lõi.

Đương nhiên, chính hạt nhân và các bộ phận của nó được kiểm tra trước khi phát hành, nhưng các thử nghiệm này chỉ bao gồm các chức năng cơ bản. Có một số hệ thống kiểm tra thực hiện kiểm tra Linux Kernel:

Dự án thử nghiệm Linux (LTP) cung cấp các bộ thử nghiệm cho cộng đồng nguồn mở xác nhận tính tin cậy và ổn định của Linux. Bộ kiểm tra LTP chứa một tập hợp các công cụ để kiểm tra nhân Linux và các tính năng liên quan. https://github.com/linux-test-project/ltp

Autotest - một khuôn khổ để thử nghiệm hoàn toàn tự động. Nó được thiết kế chủ yếu để kiểm tra nhân Linux, mặc dù nó hữu ích cho nhiều mục đích khác như kiểm tra phần cứng mới, kiểm tra ảo hóa và kiểm tra chương trình không gian người dùng chung khác trong các nền tảng Linux. Đây là một dự án nguồn mở theo GPL và được sử dụng và phát triển bởi một số tổ chức, bao gồm Google, IBM, Red Hat và nhiều tổ chức khác. http://autotest.github.io/

Ngoài ra còn có các hệ thống chứng nhận được phát triển bởi một số công ty phân phối GNU / Linux lớn. Các hệ thống này thường kiểm tra các bản phân phối GNU / Linux hoàn chỉnh để tương thích với phần cứng. Có các hệ thống chứng nhận được phát triển bởi Novell, Red Hat, Oracle, Canonical, Google .

Ngoài ra còn có các hệ thống để phân tích động của nhân Linux:

Kmemleak là một trình phát hiện rò rỉ bộ nhớ có trong nhân Linux. Nó cung cấp một cách phát hiện rò rỉ bộ nhớ kernel có thể theo cách tương tự như bộ thu gom rác theo dõi với sự khác biệt là các đối tượng mồ côi không được giải phóng mà chỉ được báo cáo qua / sys / kernel / debug / kmemleak.

Kmemcheck bẫy mọi đọc và ghi vào bộ nhớ được phân bổ động (tức là với kmalloc ()). Nếu một địa chỉ bộ nhớ được đọc mà trước đây chưa được ghi vào, một thông báo sẽ được in vào nhật ký kernel. Cũng là một phần của Linux Kernel

Khung tiêm lỗi (bao gồm trong nhân Linux) cho phép truyền các lỗi và ngoại lệ vào logic của ứng dụng để đạt được phạm vi bảo hiểm cao hơn và khả năng chịu lỗi của hệ thống.

Làm thế nào để các nhà phát triển nhân Linux kiểm tra mã của họ cục bộ và sau khi họ đã cam kết?

Họ có sử dụng một số loại thử nghiệm đơn vị, xây dựng tự động hóa?

Theo nghĩa cổ điển của từ, không.

Ví dụ. Ingo Molnar đang chạy khối lượng công việc sau: 1. xây dựng kernel mới với bộ tùy chọn cấu hình ngẫu nhiên 2. khởi động vào nó 3. goto 1

Mọi lỗi xây dựng, khởi động thất bại, BUG hoặc cảnh báo thời gian chạy đều được xử lý. 24/7. Nhân với một vài hộp, và người ta có thể phát hiện ra khá nhiều vấn đề.

kế hoạch kiểm tra?

Không.

Có thể có sự hiểu lầm rằng có cơ sở thử nghiệm trung tâm, không có. Mọi người đều làm những gì anh ấy muốn.

Dụng cụ trên cây

Một cách tốt để tìm các công cụ kiểm tra trong kernel là:

• make help và đọc tất cả các mục tiêu
• xem dưới công cụ / kiểm tra

Trong v4.0, điều này dẫn tôi đến:

• kselftest theo công cụ / thử nghiệm / selftests . Chạy với make kselftest. Phải chạy kernel dựng sẵn rồi. Xem thêm: Tài liệu / kselftest.txt , https://kselftest.wiki.kernel.org/

• ktest theo công cụ / thử nghiệm / ktest . Xem thêm: http://elinux.org/Ktest , http://www.sl slideshoware.net/satorutakeuchi18/kernel-auto-testbyktest

• Phần phân tích tĩnh của phần make helpchứa các mục tiêu như:

  • checkstack: Perl: checkstack.pl trong nguồn linux làm gì?
  • coccicheckcho Coccinelle (được đề cập bởi Askb )

Hạt nhân CI

https://kernelci.org/ là một dự án nhằm mục đích làm cho thử nghiệm kernel tự động hơn và hiển thị.

Dường như chỉ thực hiện các thử nghiệm xây dựng và khởi động (TODO cách kiểm tra tự động rằng Nguồn khởi động đã hoạt động phải có tại https://github.com/kernelci/ ).

Linaro dường như là người duy trì chính của dự án, với sự đóng góp từ nhiều công ty lớn: https://kernelci.org/sponsors/

Linaro Lava

http://www.linaro.org/initiatives/lava/ trông giống như một hệ thống CI tập trung vào sự phát triển của ban phát triển và nhân Linux.

ARM LISA

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

Không chắc chắn những gì nó làm chi tiết, nhưng đó là bởi ARM và Apache Được cấp phép, vì vậy rất có thể đáng xem.

Bản trình diễn: https://www.youtube.com/watch?v=yXZzzUEngiU

Bước gỡ lỗi

Không thực sự kiểm tra đơn vị, nhưng có thể giúp một khi các thử nghiệm của bạn bắt đầu không thành công:

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

Thiết lập QEMU + Buildroot + Python của riêng tôi

Tôi cũng đã bắt đầu thiết lập tập trung vào sự dễ dàng phát triển, nhưng cuối cùng tôi cũng đã thêm một số khả năng thử nghiệm đơn giản vào đó: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b31417t -repo

Tôi đã không phân tích tất cả các thiết lập khác rất chi tiết và chúng có thể làm được nhiều hơn so với của tôi, tuy nhiên tôi tin rằng thiết lập của tôi rất dễ dàng để bắt đầu nhanh chóng vì nó có nhiều tài liệu và tự động hóa.

Nó không phải là rất dễ dàng để tự động hóa thử nghiệm hạt nhân. Hầu hết các nhà phát triển Linux đều tự mình thử nghiệm, giống như adobriyan đã đề cập.

Tuy nhiên, có một vài điều giúp gỡ lỗi Kernel Linux:

• kexec: Một cuộc gọi hệ thống cho phép bạn đặt một kernel khác vào bộ nhớ và khởi động lại mà không cần quay lại BIOS, và nếu thất bại, hãy khởi động lại.
• dmesg: Chắc chắn là nơi để tìm kiếm thông tin về những gì đã xảy ra trong quá trình khởi động kernel và liệu nó có hoạt động / không hoạt động.
• Công cụ hạt nhân: Ngoài printk's (và một tùy chọn có tên 'CONFIG_PRINTK_TIME' cho phép bạn xem (với độ chính xác micro giây) khi kernel xuất ra cái gì), cấu hình kernel cho phép bạn bật RẤT NHIỀU công cụ theo dõi cho phép họ gỡ lỗi những gì đang xảy ra.

Sau đó, các nhà phát triển thường có người khác xem xét các bản vá của họ. Khi các bản vá được xem xét cục bộ và thấy không can thiệp vào bất cứ điều gì khác, và các bản vá được thử nghiệm để hoạt động với hạt nhân mới nhất từ ​​Linus mà không phá vỡ bất cứ điều gì, các bản vá được đẩy ngược dòng.

Chỉnh sửa: Đây là một video hay mô tả chi tiết quá trình một bản vá đi qua trước khi nó được tích hợp vào kernel.

Ngoài các điểm trên / dưới, trong đó nhấn mạnh hơn vào kiểm tra chức năng, kiểm tra chứng nhận phần cứng và kiểm tra hiệu năng của nhân Linux.

Rất nhiều thử nghiệm thực sự xảy ra thông qua, thực sự là các tập lệnh, công cụ phân tích mã tĩnh, đánh giá mã, v.v ... rất hiệu quả trong việc bắt lỗi, nếu không sẽ phá vỡ một cái gì đó trong ứng dụng.

Thưa thớt - Một công cụ nguồn mở được thiết kế để tìm lỗi trong nhân Linux.

Coccinelle là một chương trình khác thực hiện công cụ khớp và biến đổi cung cấp ngôn ngữ SmPL (Semantic Patch Language) để chỉ định các kết quả khớp và chuyển đổi mong muốn trong mã C.

checkpatch.pl và các tập lệnh khác - các vấn đề về kiểu mã hóa có thể được tìm thấy trong tệp Documentation / CodingStyle trong cây nguồn kernel. Điều quan trọng cần nhớ khi đọc nó không phải là phong cách này tốt hơn bất kỳ phong cách nào khác, chỉ là nó phù hợp. điều này giúp các nhà phát triển dễ dàng tìm và sửa các vấn đề về kiểu mã hóa, tập lệnh script / checkpatch.pl trong cây nguồn kernel đã được phát triển. Kịch bản này có thể chỉ ra các vấn đề dễ dàng và phải luôn được nhà phát triển chạy theo các thay đổi của họ, thay vì để người đánh giá lãng phí thời gian của họ bằng cách chỉ ra các vấn đề sau này.

Tôi sẽ tưởng tượng họ sử dụng ảo hóa để thực hiện các bài kiểm tra nhanh, một cái gì đó như QEMU, VirtualBox hoặc Xen và một số tập lệnh để thực hiện cấu hình và kiểm tra tự động.

Kiểm tra tự động có thể được thực hiện bằng cách thử nhiều cấu hình ngẫu nhiên hoặc một vài cấu hình cụ thể (nếu chúng đang làm việc với một vấn đề cụ thể). Linux có rất nhiều công cụ cấp thấp (như dmesg) để theo dõi và ghi nhật ký gỡ lỗi dữ liệu từ kernel, vì vậy tôi tưởng tượng rằng nó cũng được sử dụng.

Ngoài ra còn có:

MMTests là tập hợp các điểm chuẩn và tập lệnh để phân tích kết quả

https://github.com/gormanm/mmtests

Trinity là hệ thống Linux gọi trình kiểm tra fuzz

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

Ngoài ra, các trang LTP tại sourceforge khá lỗi thời và dự án đã chuyển sang GitHub https://github.com/linux-test-project/ltp

Theo như tôi biết, có một công cụ kiểm tra hồi quy hiệu suất tự động (được đặt tên là lkp / 0 ngày) do Intel điều hành, nó sẽ kiểm tra từng bản vá hợp lệ được gửi đến danh sách gửi thư và kiểm tra điểm số đã thay đổi từ các dấu hiệu vi mô khác nhau như hackbench , fio, unixbench, netperf, v.v., khi có hồi quy / cải tiến hiệu suất, một báo cáo tương ứng sẽ được gửi trực tiếp đến tác giả bản vá và các nhà bảo trì liên quan đến Cc.

LTP và Memtests thường là các công cụ ưa thích.

adobriyan đã đề cập đến vòng lặp thử nghiệm cấu hình ngẫu nhiên của Ingo. Đó là khá nhiều bây giờ được bao phủ bởi bot thử nghiệm 0 ngày (còn gọi là bot thử nghiệm kbuild). Một bài viết hay về cơ sở hạ tầng được trình bày ở đây: Kiểm tra khởi động / khởi động Kernel

Ý tưởng đằng sau thiết lập này là thông báo cho các nhà phát triển càng sớm càng tốt để họ có thể khắc phục lỗi sớm. (trước khi các bản vá biến nó thành cây của Linus trong một số trường hợp vì cơ sở hạ tầng kbuild cũng kiểm tra các cây hệ thống con của người bảo trì)

Tôi đã thực hiện biên dịch kernel linux và thực hiện một số Sửa đổi cho android (Marshmallow và Nougat) trong đó tôi sử dụng phiên bản linux 3. Tôi đã biên dịch chéo nó trong hệ thống linux, gỡ lỗi bằng tay và sau đó chạy tệp hình ảnh khởi động của nó trong Android và kiểm tra xem nó có đi vào vòng lặp hay không. Nếu nó chạy hoàn hảo thì có nghĩa là nó được biên dịch hoàn hảo theo yêu cầu hệ thống.
Đối với biên dịch hạt nhân MotoG

LƯU Ý: - Linux Kernel sẽ thay đổi theo các yêu cầu phụ thuộc vào Phần cứng hệ thống

Sau khi người đóng góp gửi tệp vá của họ và sau khi thực hiện yêu cầu hợp nhất, người gác cổng linux sẽ kiểm tra bản vá bằng cách tích hợp và xem xét nó. Một khi thành công, họ sẽ hợp nhất bản vá vào chi nhánh có liên quan và phát hành phiên bản mới. Dự án thử nghiệm Linux ( https://github.com/linux-test-project/ltp ) là nguồn chính cung cấp các kịch bản thử nghiệm (Các trường hợp thử nghiệm) để chạy với kernel sau khi áp dụng các bản vá. Điều này có thể mất khoảng 2 ~ 4 giờ và phụ thuộc. Xin lưu ý về hệ thống tập tin của hạt nhân được chọn sẽ kiểm tra lại. Ví dụ: Ext4 tạo ra các kết quả khác nhau so với EXT3 và cứ thế.

Quy trình kiểm tra hạt nhân.

1. Nhận nguồn kernel mới nhất từ ​​kho lưu trữ. ( Https://www.kernel.org/ hoặc Github.com)
2. Áp dụng tệp vá (Sử dụng công cụ Diff)
3. Xây dựng kernel mới.
4. Kiểm tra các quy trình kiểm tra trong LTP ( https://github.com/linux-test-project/ltp )