printk bên trong một handler ngắt, là nó thực sự là xấu?

Question

mọi người đều biết rằng trình xử lý ngắt phải ngắn nhất có thể. và thêm các chức năng như printk để gỡ lỗi bên trong trình xử lý ngắt là điều không nên thực hiện. Trên thực tế, tôi đã thử nó trước khi tôi gỡ lỗi hạt nhân Linux cho một thiết bị gián đoạn điều khiển char tôi viết, và nó phá hỏng thời gian của người lái xe.

Câu hỏi tôi có, là lý do tại sao điều này xảy ra? Chức năng printk được lưu vào bộ đệm! nó có nghĩa là, theo như tôi hiểu rằng dữ liệu được chèn vào trong một hàng đợi, và nó đang được xử lý sau, có lẽ nhất là sau khi trình xử lý ngắt được kết thúc.

Vậy tại sao nó không hoạt động?

Answer 1

Chức năng printk không chỉ chèn vào hàng đợi/bộ đệm - giả sử mức nhật ký đủ cao, đầu ra từ printk sẽ được phát ra ngay giao diện điều khiển, như một phần của cuộc gọi đến printk. Điều này đặc biệt chậm nếu bàn điều khiển, ví dụ, trên một cổng nối tiếp. Nhưng trong mọi trường hợp, printk không giới thiệu chi phí khá đáng kể và có thể ảnh hưởng đến thời gian.

Nếu bạn có một thời điểm quan trọng nơi bạn muốn nhận được một số đầu ra gỡ lỗi, bạn có thể xem bằng cách sử dụng chức năng trace_printk trong hạt nhân hiện đại. Điều này thực sự không chỉ đưa đầu vào vào dấu vết vòng, và bạn có thể đọc nó sau này. Hãy xem this article để biết chi tiết đầy đủ.

Answer 2

Có, rất xấu vì printf có thể không phải là reentrant. Điều gì có thể xảy ra là chương trình chính gọi printf, một ngắt đến trong khi printf đang thực hiện, và sau đó xử lý IRQ gọi printf một lần nữa: những điều rất xấu có thể xảy ra (ví dụ: bế tắc, bộ đệm nội bộ hỏng, v.v.)