- Mã Rust triển khai API Direct Memory Access đã được gửi dưới dạng pull request lên kho lưu trữ nhân Linux.
- Christoph Hellwig, một người quản lý cấp trung của nhân Linux, đã từ chối với lý do không nên đưa mã Rust vào nhân Linux, và tranh chấp bắt đầu.
- Khi quy mô tranh chấp ngày càng lớn, Christoph Hellwig đã ví Rust như tế bào ung thư.
- Hector Martin, người đứng đầu Asahi Linux, đã phản ứng trước phát ngôn “tế bào ung thư” này và dữ dội chỉ trích trên mạng xã hội, đồng thời lôi cả Linus Torvalds vào cuộc.
- Linus Torvalds đã cảnh báo Hector Martin rằng “vấn đề nằm ở chính bạn” và “đừng vận động dư luận trên mạng xã hội (brigading)”.
- Hiện tại, Hector Martin đang xin từ chức khỏi vị trí quản lý mã Linux upstream hỗ trợ phần cứng tương thích Apple Arm.
28 bình luận
Bản tóm tắt chỉ nhắc đến những sự việc đã xảy ra, nhưng ở cuối bài gốc (bằng tiếng Hàn) còn có thêm 2 thông tin nền bổ sung để hiểu rõ hơn về sự việc.
Tôi nghĩ việc quản lý một dự án bằng một ngôn ngữ duy nhất là tốt, nhưng ngoài chuyện đó ra thì cách thuyết phục đồng nghiệp về điều này đúng là tệ nhất.
Ép người khác phải khuất phục bằng quyền lực là điều phi lý.
Đây là thread mail của PR đó:
https://lwn.net/ml/all/…
Có vẻ đây không phải là PR sửa phần triển khai DMA, cũng không phải trực tiếp đụng vào DMA API, mà là PR viết FFI binding để có thể truy cập DMA API từ Rust.
Thế mà PR như vậy lại bị từ chối bằng một câu cụt lủn: "No rust code in kernel/dma, please." và đây là link: https://lwn.net/ml/all/20250108135951.GA18074@lst.de/
Khi được hỏi vậy thì nên làm thế nào, người đó trả lời: "Keep the wrappers in your code instead of making life painful for others." https://lwn.net/ml/all/20250108151858.GB24499@lst.de/
(Thực ra đúng là đã làm theo như vậy. PR này không sửa kernel/dma mà sửa subtree bên dưới rust/kernel.)
Dĩ nhiên, nếu thêm FFI binding thì khi DMA API thay đổi, phía Rust FFI binding cũng sẽ phải sửa theo, nên đúng là có thêm gánh nặng như vậy,
nhưng dù bên đụng tới Rust đã nói rằng họ sẽ tự lo phần đó, tôi vẫn không rõ việc một người không phụ trách tree đó lại phản đối với thái độ như vậy có đúng hay không.
(Christoph Hellwig là maintainer của kernel/dma: https://docs.kernel.org/process/maintainers.html#dma-mapping-helpers)
Vì thế có lẽ Hector Martin đã kéo Linus vào thread này:
https://lwn.net/ml/all/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/
Nhưng điều thú vị là ngay ở thread trước đó có một ý như thế này,
nếu API có breaking change mà đội Rust không phản ứng đủ nhanh thì bản build sẽ vỡ và Linus sẽ không nhận PR.
Dù sao, nếu nghĩ đây là vấn đề giữa module tạo ra breaking change và một module khác, thì cá nhân tôi lại thấy phía có Rust tốt hơn.
Giả sử module x tạo ra breaking change, còn module y không kịp phản ứng, thì:
Trong kernel Linux, những phần Rust dùng
unsafephần lớn là các đoạn bọc để tương tác với C.Ngoài ra cũng có một số rất ít phần điều khiển phần cứng cần thao tác trực tiếp với bộ nhớ.
Phần được áp dụng Rust là phát triển driver. Không cần đụng tới, và cũng không thể đụng tới, bản thân kernel như quản lý bộ nhớ hay block layer.
Lượng mã driver còn nhiều hơn rất nhiều so với mã của chính kernel. Và phần lớn những điểm phát sinh vấn đề cũng là ở mã driver.
Tôi nghĩ phần phát triển driver nên được viết bằng một ngôn ngữ có độ an toàn bộ nhớ và bảo mật tốt hơn C.
Dù đó là Rust, Zig hay thứ gì khác thì tôi cũng không chắc.
Tôi cũng đồng ý rằng Rust quá phức tạp để phát triển ứng dụng thông thường, và cũng khó để các lập trình viên C học nhanh.
Dù vậy, tôi vẫn hy vọng ít nhất riêng mảng phát triển driver sẽ được chuyển sang một ngôn ngữ hiện đại hơn, bất kể đó là ngôn ngữ nào.
Ở công ty cũ, tôi từng mất khoảng 7 năm để phát triển và ổn định hóa một driver chỉ vài nghìn dòng, và dù không thể đơn giản hóa hoàn toàn, có lẽ khoảng 3 năm trong số đó chỉ là để debug.
Phần lớn là lỗi liên quan đến bộ nhớ. Những lỗi logic như deadlock thì chỉ chiếm số ít.
Có vẻ không ổn khi dùng các dự án lớn làm nơi thử nghiệm cho ngôn ngữ của mình.
Nếu không hợp thì cũng nên quay lại thời trước, khi cứ tách nhánh nếu cần.
Với một kernel xử lý toàn bộ thiết bị, tôi chỉ thấy rằng dù có dùng Rust thì một khi bắt đầu dùng
unsafe, cuối cùng cũng thành ra loại mã khó đọc và dễ phát sinh vấn đề.Đây cũng đâu phải kiểu dự án không có bản phát hành chính thức rõ ràng như 0.91, 0.92, 0.99, 0.991 gì đó, nên tôi không hiểu vì sao lại đi port cả những phần vốn đang chạy tốt.
Cũng chẳng phải là nhân lúc sửa một lỗi lớn thì tiện thể chuyển sang cách an toàn hơn.
PR này không phải là port. Đây là PR thêm các ràng buộc FFI ở phía Rust để có thể dùng API DMA hiện có cả trong các mô-đun viết mới dựa trên Rust. Và người phụ trách DMA đã chặn việc đó.
Thật tiếc là phần thân bài không có trích dẫn nguyên văn. Vì tò mò nên tôi đã tự tìm bản gốc và đọc thử; dù tôi cũng chưa nắm hết được một cách chính xác, nhưng có vẻ là có khá nhiều câu chuyện phía sau, nên khó mà chỉ kể lại đơn giản như nguyên văn được.
Tiêu đề của bài viết đã được đổi thành tên gốc.
Cảm ơn bạn đã xử lý.
Hóa ra việc gắn Rust vào một codebase C lớn không thú vị như tưởng tượng. Nếu nói là để tăng độ an toàn bộ nhớ thì rốt cuộc vùng
unsafecũng phình ra nên hiệu quả thực tế không lớn lắm.... Nó dường như không mang nhiều ý nghĩa ngoài việc phạm vi sử dụng Rust ngày càng rộng hơn.... nên việc gây ra phản ứng ngược từ các lập trình viên C hiện có có lẽ là diễn biến khá tự nhiên. Có lẽ sẽ tốt hơn nếu tập trung vào một dự án kernel thực sự được bắt đầu bằng Rust ngay từ đầu.Ồ, chất lượng phần nội dung tốt hơn tôi nghĩ đấy, đọc rất thú vị.
Điều Torvalds muốn nói khi bảo rằng vấn đề nằm ở chính bạn là, bất kể việc áp dụng Rust hay không, lời giải cho các vấn đề kỹ thuật không thể đến từ SNS; nhưng nếu chỉ nhìn vào phần tóm tắt này thì có vẻ khá dễ gây hiểu lầm.
Đó là một lựa chọn không thể tránh khỏi đối với Hector Martin.
Khi tầng quản lý trung gian của Linux đều kín chỗ bởi các chuyên gia C, thì làm sao họ lại chịu tiếp nhận những ý kiến của số ít lập trình viên Rust chứ.
https://youtu.be/opTJH76wJxs?si=WHR0_1uPpSlpDTHr cho thấy quá trình mọi thứ leo thang thành một cuộc tranh cãi.
Chẳng phải Torvalds cũng cho phép Rust sao?
Torvalds không nói một lời nào về Rust trong cuộc tranh luận đó.
Khi có tranh chấp về ý kiến kỹ thuật, thì phải thảo luận dựa trên cơ sở kỹ thuật,
chứ đừng tìm cách kết thúc tranh chấp bằng việc tạo dư luận trên SNS.
Nếu giỏi đến thế thì hãy fork kernel rồi viết toàn bộ bằng Rust đi. Đừng có lén lút len vào như ung thư nữa. Có vẻ có khá nhiều ý kiến như vậy.
Nếu đó là đoạn mã đụng vào phía
kernel/dmađể làm cho dễ dùng hơn từ Rust thì còn chưa biết, nhưng đó là đoạn mã thêm một lớp FFI bọckernel/dmavàorust/kernel/dma.Nó không hề sửa mã gốc.
Thực chất, điểm cốt lõi là kiểu như:
Tôi không thích việc người ta dùng sai DMA FFI chính thức được viết cho Rust rồi lại hỏi tôi...
Thế rồi lại nói một câu trước sau không khớp là cứ để từng driver tự lo tạo FFI ở phía mình.
Đó là Redox đấy. Chắc là vì vẫn còn những phần chưa được hỗ trợ nên mới chuyển sang Linux thôi...
https://vt.social/@lina/113064510447670892
Nội dung bạn viết có vẻ hoàn toàn đúng như những gì Hellwig đã phát biểu, nhưng tôi không chắc có thể xem đó là ý kiến của đa số hay không.
Xin chào. Cảm ơn bạn đã đăng một bài viết hay. Tôi đã đọc rất thích.
Tuy nhiên, sau khi kiểm tra bài gốc và xem tiêu đề gốc, tôi có đôi chút lo ngại nên xin để lại bình luận.
https://news.hada.io/guidelines
> Về cơ bản, vui lòng dùng tiêu đề gốc của bài viết, hoặc dịch tiêu đề sang tiếng Hàn rồi đăng lên.
Có đề xuất như vậy, và khi đọc nội dung bài viết này, tôi nghĩ rằng tiêu đề "Linus Torvalds 'Vấn đề là ở bạn'" thay cho "Tranh cãi về Rust trong Linux kernel lại bùng lên" thậm chí còn dễ khiến người đọc hiểu sai nội dung bài viết hơn cả tiêu đề gốc.
Một lần nữa xin cảm ơn bạn vì đã tóm tắt và giới thiệu bài viết. Chúc bạn một ngày tốt lành.
Đỉnh quá
Tôi sẽ tham khảo.
'm 'b Chúc bạn một ngày tốt lành! Cảm ơn bạn, nhờ vậy tôi đã được đọc một bài viết hay. (__ )
Tôi có thói quen thêm phụ đề riêng vào tiêu đề để giải thích chính xác hơn, nhưng có vẻ tiêu đề đó không phù hợp với người khác, hơn nữa tôi cũng không biết là có quy định như vậy. Từ lần sau tôi sẽ đăng nguyên văn tiêu đề gốc.
Tiêu đề gốc cho biết ngay câu chuyện nói về điều gì, trong khi tiêu đề anh/chị đã sửa có vẻ dễ khiến người ta hiểu nhầm là mang tính giật tít. Đây là ý kiến cá nhân của tôi.
Cảm ơn bạn đã góp ý.
Tôi cho rằng phát biểu của Linus là quan trọng nhất nên đã đưa nó vào tiêu đề, nhưng có vẻ như điều đó đã làm méo mó nội dung khá nhiều.
Tôi chắc chắn sẽ cẩn trọng hơn.