Khi nào tôi nên viết một mô-đun hạt nhân Linux?

Question

Một số người muốn di chuyển mã từ không gian người dùng sang không gian hạt nhân trong Linux vì một số lý do. Rất nhiều lần lý do dường như là mã nên có ưu tiên đặc biệt cao hoặc đơn giản là "không gian hạt nhân nhanh hơn".

Điều này có vẻ lạ đối với tôi. Khi nào tôi nên xem xét viết một mô-đun hạt nhân? Có một tập hợp các tiêu chí?

Làm cách nào tôi có thể thúc đẩy việc giữ mã trong không gian người dùng mà (tôi tin) thuộc về đó?

Answer 1

Tôi không chắc chắn câu hỏi là đúng cách. Nên có một lý do chính đáng để chuyển mọi thứ sang không gian hạt nhân. Nếu không có lý do gì, đừng làm thế.

Đối với một điều, gỡ lỗi được thực hiện khó khăn hơn, và hiệu quả của lỗi là tồi tệ hơn (tai nạn/hoảng sợ thay vì coredump đơn giản).

Answer 2

Mã chạy trong hạt nhân truy cập bộ nhớ, thiết bị ngoại vi, chức năng hệ thống theo các cách khác với mã vùng người dùng và do đó có khả năng hiệu quả hơn. Chưa kể đến các hạn chế bảo mật đã giảm đối với mã hạt nhân. Tuy nhiên, tất cả điều này thường đi kèm với chi phí, chẳng hạn như tăng khả năng mở hạt nhân lên đến các mối đe dọa bảo mật, khóa hệ điều hành, làm phức tạp việc gỡ lỗi, v.v.

Answer 3

Có rất ít lý do để đưa nội dung vào hạt nhân. Nếu bạn đang viết trình điều khiển thiết bị thì không sao. Bất kỳ ứng dụng tiêu chuẩn nào: không bao giờ.

Những hạn chế là rất lớn. Gỡ lỗi trở nên khó khăn hơn, lỗi trở nên thường xuyên hơn và khó tìm hơn. Bạn có thể thỏa hiệp an ninh và ổn định. Bạn có thể phải thích nghi với các thay đổi hạt nhân thường xuyên hơn. Nó không thể chuyển sang các hệ điều hành UNIX khác.

Gần nhất tôi từng đến hạt nhân là hệ thống tệp tùy chỉnh (với mysql ở chế độ nền) và ngay cả khi chúng tôi sử dụng FUSE (trong đó U là viết tắt của không gian người dùng).

Answer 4

Như quy tắc chung. Hãy suy nghĩ về những gì bạn muốn biết và nếu đó là một cái gì đó bạn sẽ thấy trong một cuốn sách phát triển hệ điều hành hoặc lớp học sau đó nó có một cơ hội tốt để thuộc về hạt nhân. Nếu không, hãy giữ nó ra khỏi hạt nhân. Nếu bạn có một lý do rất tốt để phá vỡ quy tắc đó, hãy chắc chắn, bạn sẽ có đủ kiến ​​thức để biết điều đó một mình hoặc bạn sẽ làm việc với một người có kiến ​​thức đó.

Có, có thể âm thanh khắc nghiệt, nhưng điều này chính xác những gì tôi có nghĩa là, nếu bạn không biết, sau đó được gần như chắc chắn câu trả lời là không, không làm điều đó trong hạt nhân. Di chuyển sự phát triển của bạn sang không gian hạt nhân sẽ mở ra một loại sâu khổng lồ mà bạn phải chắc chắn để có thể xử lý.

Answer 5

Quy tắc chung: hãy thử tuyệt đối tốt nhất để giữ mã của bạn trong không gian người dùng. Nếu bạn không nghĩ rằng bạn có thể, dành nhiều thời gian nghiên cứu các lựa chọn thay thế cho mã hạt nhân như bạn viết mã (ví dụ: một thời gian dài), và sau đó thử lại để triển khai nó trong không gian người dùng. Nếu bạn vẫn còn không thể, nghiên cứu thêm để đảm bảo bạn đang đưa ra lựa chọn đúng, thì rất thận trọng di chuyển vào hạt nhân. Như những người khác đã nói, có rất ít trường hợp quyết định viết mô-đun hạt nhân và gỡ lỗi mã hạt nhân có thể khá địa ngục, vì vậy chỉ đạo rõ ràng bằng mọi giá. Theo các điều kiện cụ thể, bạn nên kiểm tra khi xem xét viết mã chế độ hạt nhân, dưới đây là một số ít: Có cần truy cập vào các tài nguyên cấp thấp, chẳng hạn như ngắt không? Không.Mã của bạn có xác định giao diện/trình điều khiển mới cho phần cứng mà không thể được xây dựng trên chức năng hiện được xuất không? Mã của bạn có yêu cầu truy cập vào cấu trúc dữ liệu hoặc nguyên thủy không được xuất ra khỏi không gian hạt nhân không? Bạn có đang viết cái gì đó chủ yếu được sử dụng bởi các hệ thống con khác, chẳng hạn như lịch biểu hoặc hệ thống VM (ngay cả ở đây không hoàn toàn cần thiết là hệ thống con là chế độ hạt nhân: Mach có hỗ trợ mạnh mẽ cho chế độ người dùng máy nhắn tin bộ nhớ ảo, vì vậy nó chắc chắn có thể được thực hiện)?

Answer 6

Nếu người của bạn muốn ưu tiên thực sự cao, tính quyết định, độ trễ thấp vv, đúng cách để đi là sử dụng một số phiên bản Linux thời gian thực (hoặc hệ điều hành khác).

Đồng thời xem xét các tùy chọn hạt nhân được ưu tiên. Chính xác những gì bạn nên làm phụ thuộc vào yêu cầu, nhưng để đặt mã trong mô-đun hạt nhân thì không phải là giải pháp đúng, trừ khi bạn đang giao tiếp trực tiếp với phần cứng.

Answer 7

Nếu bạn chỉ cần độ trễ thấp hơn, thông lượng cao hơn, v.v., có thể là rẻ hơn để mua máy tính nhanh hơn để phát triển mã hạt nhân.

Kernel module thể được nhanh hơn (do tắc ít bối cảnh, ít hệ thống gọi trên cao, và sự gián đoạn ít hơn), và chắc chắn làm chạy ở mức ưu tiên rất cao. Nếu bạn muốn xuất một lượng nhỏ mã khá đơn giản vào không gian hạt nhân, điều này có thể là OK. Tức là, nếu một đoạn mã nhỏ được tìm thấy là rất quan trọng đối với hiệu suất, thì và là loại mã sẽ được hưởng lợi từ việc được đặt ở chế độ hạt nhân, sau đó có thể được hợp lý để đặt nó ở đó.

Nhưng tránh di chuyển các phần lớn của chương trình vào không gian hạt nhân trừ khi tất cả các tùy chọn khác hoàn toàn cạn kiệt. Bên cạnh những khó khăn khi làm như vậy, lợi ích hiệu suất không có khả năng là rất lớn.

Answer 8

Về cơ bản, tôi đồng ý với rpj. Mã phải nằm trong không gian người dùng, trừ khi nó thực sự cần thiết.

Nhưng, để nhấn mạnh câu hỏi của bạn, điều kiện nào?

Một số người cho rằng trình điều khiển phải nằm trong hạt nhân, điều này không đúng. Một số trình điều khiển không phải là thời gian nhạy cảm, trên thực tế rất nhiều trình điều khiển được như thế.

Ví dụ: bộ khung, bộ định thời RTC, thiết bị i2c, vv Các trình điều khiển đó có thể dễ dàng di chuyển đến không gian người dùng. Thậm chí còn có một số hệ thống tệp được viết trong không gian người dùng.

Bạn nên di chuyển đến không gian hạt nhân, nơi trên đầu, ví dụ: hoán đổi hạt nhân của người dùng, trở thành không thể chấp nhận để mã của bạn hoạt động bình thường.

Nhưng có rất nhiều cách để giải quyết vấn đề này. Ví dụ,/dev/mem cung cấp một cách tốt để truy cập bộ nhớ vật lý của bạn, giống như bạn làm điều đó từ không gian hạt nhân.

Khi mọi người nói về việc chuyển sang RTOS, tôi thường hoài nghi. Những ngày này, bộ vi xử lý mạnh mẽ đến nỗi hầu hết thời gian, khía cạnh thời gian thực trở nên không đáng kể. Nhưng thậm chí, giả sử bạn đang giao dịch với SONET và bạn cần thực hiện chuyển đổi bảo vệ trong phạm vi 50ms (thậm chí còn ít hơn, vì các ràng buộc 50ms áp dụng cho toàn bộ vòng), bạn vẫn có thể thực hiện chuyển đổi rất nhanh, nếu phần cứng của bạn hỗ trợ nó.

Rất nhiều khung thời gian trong những ngày này có thể cung cấp cho bạn hỗ trợ phần cứng giúp giảm số lượng ghi mà bạn cần thực hiện. Công việc của bạn về cơ bản là đáp ứng với sự gián đoạn càng nhanh càng tốt. Và Linux không tệ chút nào. Độ trễ gián đoạn tôi nhận được ít hơn 1ms, ngay cả khi tôi có hàng tấn gián đoạn khác đang chạy (ví dụ: IDE, ethernet, v.v.).

Và nếu điều đó vẫn chưa đủ, thì có thể thiết kế phần cứng của bạn sai. Một số điều tốt hơn còn lại trên phần cứng. Và khi tôi nói phần cứng, tôi có nghĩa là ASIC, FPGA, Bộ xử lý mạng hoặc logic nâng cao khác.

Answer 9

Nếu bạn đang đặt câu hỏi như vậy, thì bạn không nên chuyển đến lớp hạt nhân. Về cơ bản chỉ cần tự hỏi có nghĩa là bạn không cần phải. Thời gian của việc chuyển đổi ngữ cảnh là không đáng kể đến mức nó không quan trọng vào những ngày này.

Answer 10

Một lý do khác để không chuyển mã vào không gian hạt nhân là khi bạn sử dụng mã đó trong các tình huống sản xuất hoặc thương mại, bạn sẽ phải xuất bản mã đó do thỏa thuận GPL. Một tình huống mà nhiều công ti phần mềm không muốn thâm nhập. :)