Location via proxy:   [ UP ]   [Report a bug]   [Manage cookies]    No cookies    No scripts    No ads    No referrer    Show this form

https://lwn.net/Articles/978738/ This is a special feed containing comments posted to the individual LWN article titled "Rust for filesystems". en-us Wed, 16 Oct 2024 09:24:45 +0000 Wed, 16 Oct 2024 09:24:45 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net https://lwn.net/Articles/994373/ https://lwn.net/Articles/994373/ taladar <div class="FormattedComment"> It is the way the order of those statements work in all languages I am aware of, from simple assignments over destructuring bind in Common Lisp and pattern matching in languages like Haskell.<br> </div> Wed, 16 Oct 2024 08:20:16 +0000 https://lwn.net/Articles/994270/ https://lwn.net/Articles/994270/ Rudd-O <div class="FormattedComment"> <span class="QuotedText">&gt; "foo::bar =&gt; &lt;blah:::xyz&gt;" incomprehensible gibberish... :D</span><br> <p> I found this exceedingly difficult to wrap around, the `match` and `if let` constructs felt backwards in a very weird way.<br> <p> I got used eventually, but it was a solid month until it "clicked".<br> <p> Now it annoys me that other languages don't do this.<br> </div> Tue, 15 Oct 2024 13:46:45 +0000 https://lwn.net/Articles/982687/ https://lwn.net/Articles/982687/ farnz <p>Just FYI, Rust has <tt><a href="https://doc.rust-lang.org/nomicon/other-reprs.html#reprc">#[repr(C)]</a></tt> to tell the compiler to lay out a data structure in a fashion compatible with the platform's C ABI. <a href="https://github.com/mozilla/cbindgen/blob/HEAD/docs.md">cbindgen (where the source of truth is Rust code)</a> and <a href="https://rust-lang.github.io/rust-bindgen/">bindgen (where the source of truth is C code)</a> make use of this to produce matching representations in C and Rust for the same data structure. Sat, 20 Jul 2024 15:51:18 +0000 https://lwn.net/Articles/982685/ https://lwn.net/Articles/982685/ kevincox <div class="FormattedComment"> <span class="QuotedText">&gt; different C compilers could lay things out differently</span><br> <p> I don't think this is true. I don't think the C standard cares (other than some basic restrictions on possible layouts) but platform ABIs will strictly define how structs are laid out, just like they define how arguments are laid out, what object files look like and everything else.<br> <p> For example if you compile code with Clang and GCC on x86_64 Linux they will be binary compatible as they all follow the same ABI specification (IIRC it is the System V AMD64 ABI). There is no reason why the Rust compiler couldn't follow the same rules for structures that are shared with C (even if it uses a more efficient and unstable layout for internal structures).<br> </div> Sat, 20 Jul 2024 15:13:52 +0000 https://lwn.net/Articles/982294/ https://lwn.net/Articles/982294/ andresfreund <div class="FormattedComment"> Wol. You regularly post close to half of the comments here. I'd appreciate if you could try to appreciate the perspective of the readers of the comment section into consideration a bit more. Nobody writes *that* much interesting stuff.<br> </div> Wed, 17 Jul 2024 16:55:43 +0000 https://lwn.net/Articles/982271/ https://lwn.net/Articles/982271/ Wol <div class="FormattedComment"> <span class="QuotedText">&gt; I mean is it any more annoying or destructive than the "Everything must be written in rust" evangelism that many of the rust fans parrot?</span><br> <p> Rust FANS, or Rust PROGRAMMERS.<br> <p> Generally you'll find the people who make the most noise, are the people who do the least work. That's not always a bad thing, you need your evangelists (after all, I make a heck of a lot of noise about Pick/MV), but there are too many people who think it's a silver bullet when they've never really used it.<br> <p> It DOES sound great. And given that all the evidence says it's not vulnerable to a huge class of errors that regularly bite C/C++, there's good reason to - as a minimum - try it out. But it's noticeable that a lot of people are too busy using it to evangelise it. That to me is a good sign.<br> <p> Cheers,<br> Wol<br> </div> Wed, 17 Jul 2024 13:40:37 +0000 https://lwn.net/Articles/982224/ https://lwn.net/Articles/982224/ that_kca <div class="FormattedComment"> <span class="QuotedText">&gt; I find the attitude of "I don't care about Rust, I'll not learn Rust" annoying and destructive.</span><br> <p> I mean is it any more annoying or destructive than the "Everything must be written in rust" evangelism that many of the rust fans parrot?<br> <p> I imagine if rust spent less of the design/engineering points in being hard to learn the language might find more people willing to pick it up. <br> <p> But then the majority of the rust internet community would probably run to something else.<br> </div> Wed, 17 Jul 2024 12:19:01 +0000 https://lwn.net/Articles/981972/ https://lwn.net/Articles/981972/ ssokolow ...but do also keep this quote in mind: <blockquote> Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence. -- Edsger W. Dijkstra, "The Humble Programmer" (1972) </blockquote> Mon, 15 Jul 2024 02:49:55 +0000 https://lwn.net/Articles/980619/ https://lwn.net/Articles/980619/ mrugiero <div class="FormattedComment"> <span class="QuotedText">&gt; Now, encode all that information into a type system? Not sure it can be done.</span><br> <p> There's the option to not do that in Rust, too. The type system is quite useful most of the time, but there is a point of diminishing returns and at that point you rely on runtime checks and discipline just like in any other language.<br> </div> Thu, 04 Jul 2024 02:34:02 +0000 https://lwn.net/Articles/980618/ https://lwn.net/Articles/980618/ mrugiero <div class="FormattedComment"> <span class="QuotedText">&gt; I think it's entirely reasonable to ask maintainers to also care about the Rust code.</span><br> <p> I'm not sure if I'm inventing this, but I believe the deal was that maintainers got to decide whether Rust made it into in their subsystems? If that's the case, it's only reasonable to expect them to either reject the patches or commit to keep them working. Otherwise we're in a kind of Seinfeld's car reservation situation.<br> </div> Thu, 04 Jul 2024 02:23:08 +0000 https://lwn.net/Articles/980617/ https://lwn.net/Articles/980617/ mrugiero <div class="FormattedComment"> OTOH, isn't fixing what you break the general etiquette? I don't think "I don't know this" works as an excuse in other cases. You don't get to leave XFS broken if you touch VFS because you don't know XFS. Rust is not even that hard to learn when you come from C (also knowing C++ helps a lot as well, since Rust is pretty much C++ best practices enforced by the compiler), it's not frontend programmers we're dealing with.<br> </div> Thu, 04 Jul 2024 02:16:54 +0000 https://lwn.net/Articles/980616/ https://lwn.net/Articles/980616/ mrugiero <div class="FormattedComment"> That won't be a problem. Most kernel development is made by employees of companies with the ability to promote, deliver bonuses and firing, and they'd rather have their kernel maintained, be it in C, Rust or Pascal. You are right for the general case though, most open source projects are driven by volunteers. Linux is an exception to that rule.<br> </div> Thu, 04 Jul 2024 02:13:22 +0000 https://lwn.net/Articles/979635/ https://lwn.net/Articles/979635/ NYKevin <div class="FormattedComment"> <span class="QuotedText">&gt; I remember reading somewhere, that the speed at which a good programmer could produce good code was measured in LoC, REGARDLESS OF THE LANGUAGE USED. </span><br> <p> This is less surprising than it sounds. It basically amounts to "higher level languages allow programmers to write code that does more elaborate things in the same amount of development time," which had darned well better be true considering all of the performance cost of e.g. Python. If Python didn't give you a development speed advantage, there would be no (or at least much less) reason to use it for serious purposes (outside of the classroom).<br> </div> Tue, 25 Jun 2024 17:20:29 +0000 https://lwn.net/Articles/979616/ https://lwn.net/Articles/979616/ farnz <p>The other thing to bear in mind is that different languages have different challenge levels when you're not very good at them. At one extreme, you have languages where just about everything you could reasonably consider "language source code" is accepted by implementations as "valid" code, and if you barely understand the language, it's really hard to avoid making mistakes. <p>At the other extreme, you have languages where the compiler will definitely complain if you make a change that won't work, and thus it's a lot easier to avoid making mistakes because the compiler tells you that what you've implemented is not going to work. <p>And in the middle of those two extremes, we have real languages, where some things that won't work cause the compiler to complain (such as including a file that doesn't exist like <tt>#include &lt;linus/asm.h&gt;</tt>), while other things that won't work compile and fail later. <p>The interesting question is whether Rust is strict enough that someone with good C skills and minimal Rust skills can be confident that the Rust toolchain will complain if they make the "obvious" fix, but it's wrong, or whether they have to learn more Rust so that they can do the checks themselves (or ask someone else to check their work). Tue, 25 Jun 2024 15:40:48 +0000 https://lwn.net/Articles/979622/ https://lwn.net/Articles/979622/ b7j0c <div class="FormattedComment"> both Microsoft and Google appear to be able to introduce Rust into existing codebases - but they also have the power to promote, deliver bonuses, or alternatively, fire people who aren't aligned with the strategy<br> <p> open source projects are different...volunteers can just move on if they are unhappy, and if you don't have suitable replacement volunteers, things stop happening<br> <p> <p> </div> Tue, 25 Jun 2024 15:23:58 +0000 https://lwn.net/Articles/979620/ https://lwn.net/Articles/979620/ somlo <div class="FormattedComment"> Having never used the Go language, I managed to "cut'n'paste" my way into writing a useful (and also stylistically and functionally correct) patch against Docker. So in principle you *should* be right about your first level of "knowing" a language concept.<br> <p> However, unlike Go, I find Rust hard to skim over -- for the lack of a better word, it's too "syntax-y" for my brain :) So your "anyone should be able to deal with it" statement is actually a much bigger ask than you think, depending on the actual language's legibility to newcomers.<br> <p> I then tried working my way through "The Rust Programming Language", and was mostly able to follow along and understand what's going on, and even managed to write ok-ish small programs in the process.<br> <p> But without being a real, $DAYJOB Rust programmer, when I look at production code a few months later, it's back to a wall-of-syntax "foo::bar =&gt; &lt;blah:::xyz&gt;" incomprehensible gibberish... :D<br> This may be just an undiagnosed learning disability on my part, or it might be that Rust syntax is simply less legible to a large swath of the otherwise OK programmer population.<br> <p> I'm also constantly high-key annoyed at how compiling a program involves downloading crap off the Internet, as part of the compilation process (this is the part where I might just be old and grumpy, and the whole download-crap-from-the-Internet thing is interfering with my lawn care routine).<br> <p> Anyhow, if kernel maintainers' experience is anything like mine, I can't blame them for putting a "low pass filter" on this thing: maybe it goes away if they ignore it long enough, and they won't have to waste time on it.<br> <p> Now, if based on the description of my pain points above there's a more targeted way of learning Rust in a way that sticks, I'm happy to take hints and advice...<br> </div> Tue, 25 Jun 2024 14:51:46 +0000 https://lwn.net/Articles/979615/ https://lwn.net/Articles/979615/ pizza <div class="FormattedComment"> <span class="QuotedText">&gt; I think it's entirely reasonable to ask maintainers to also care about the Rust code.</span><br> <p> I agree in principle -- but we're a long, long way from the "ongoing maintenance" phase. <br> <p> The current status quo is that, in order to meaningfully contribute to kernel-Rust, you have to essentially be an expert in all-things-Rust, including living on the bleeding edge of Rust language/feature development.<br> <p> <span class="QuotedText">&gt; I find the attitude of "I don't care about Rust, I'll not learn Rust" annoying and destructive.</span><br> <p> You may find it annoying but it is an entirely rational (and reasonable!) attitude to take given that hyper-unstable nature of kernel-Rust and the already-overwhelming "just maintaining existing stuff" workload. <br> <p> After all, "Let those who care about X do the work" has been the kernel development philosophy since approximately forever.<br> </div> Tue, 25 Jun 2024 14:36:52 +0000 https://lwn.net/Articles/979608/ https://lwn.net/Articles/979608/ zuki <div class="FormattedComment"> I find the attitude of "I don't care about Rust, I'll not learn Rust" annoying and destructive.<br> <p> There's also the distinction that there are different levels of "knowing" a language. It's quite easy to get to the level where one can do small modifications to existing code, or to copy existing functionality and extend it to cover additional cases. It's much harder to know which of the many possible ways of structuring code and which abstractions to use for a new problem. But fortunately, for ongoing maintenance, this first easier level is all that is needed. The second higher level is only necessary e.g. to implement or review new Rust abstractions in the kernel or new drivers, but a different set of people can handle that.<br> <p> I think it's entirely reasonable to ask maintainers to also care about the Rust code.<br> </div> Tue, 25 Jun 2024 13:36:46 +0000 https://lwn.net/Articles/979572/ https://lwn.net/Articles/979572/ Wol <div class="FormattedComment"> <span class="QuotedText">&gt; &gt; I'm not talking of a full-scale migration; a non-trivial or undeniable level of adoption is enough.</span><br> <p> <span class="QuotedText">&gt; In other words, "The inevitability of Rust becoming a requirement to build a usable/useful kernel."</span><br> <p> Which, if the claims of the speed with which good solid drivers can be written in Rust are true, is inevitable sooner rather than later ...<br> <p> I remember reading somewhere, that the speed at which a good programmer could produce good code was measured in LoC, REGARDLESS OF THE LANGUAGE USED. In other words, measured in terms an end user could understand - what a system could do - the choice of language has a major impact on productivity.<br> <p> Cheers,<br> Wol<br> </div> Tue, 25 Jun 2024 12:13:56 +0000 https://lwn.net/Articles/979571/ https://lwn.net/Articles/979571/ pizza <div class="FormattedComment"> <span class="QuotedText">&gt; I'm not talking of a full-scale migration; a non-trivial or undeniable level of adoption is enough.</span><br> <p> In other words, "The inevitability of Rust becoming a requirement to build a usable/useful kernel."<br> <p> ...All it takes is one driver (not even subsystem), and *BAM* you're now a Rust system with a (substantial) pile of C.<br> <p> (Or rather, "kernel-Rust" with a pile of "kernel-C")<br> <p> <p> <p> <p> <p> <p> </div> Tue, 25 Jun 2024 11:57:34 +0000 https://lwn.net/Articles/979567/ https://lwn.net/Articles/979567/ pbonzini <div class="FormattedComment"> I'm not talking of a full-scale migration; a non-trivial or undeniable level of adoption is enough.<br> </div> Tue, 25 Jun 2024 10:42:11 +0000 https://lwn.net/Articles/979566/ https://lwn.net/Articles/979566/ b7j0c <div class="FormattedComment"> <span class="QuotedText">&gt; What will _actually_ happen is a mix of three things:</span><br> <p> treating the migration to Rust as inevitable feels like magical thinking, same as Mozilla experienced with Servo<br> <p> <p> </div> Tue, 25 Jun 2024 08:42:21 +0000 https://lwn.net/Articles/979555/ https://lwn.net/Articles/979555/ riking <div class="FormattedComment"> <a href="https://p4.org/">https://p4.org/</a> is a programmable packet processing specification language. You use it to write firewall or routing rules, or queue dropping priorities, or whatever the hardware of the router you bought allows you to load a P4 program to do.<br> </div> Mon, 24 Jun 2024 22:04:16 +0000 https://lwn.net/Articles/979454/ https://lwn.net/Articles/979454/ LtWorf <div class="FormattedComment"> "do not break user space" only applies to syscalls basically.<br> <p> If a filesystem stops working, that has never counted as "userspace is now broken".<br> </div> Mon, 24 Jun 2024 06:27:45 +0000 https://lwn.net/Articles/979434/ https://lwn.net/Articles/979434/ softball <div class="FormattedComment"> They are possibly referring to: <a href="https://lwn.net/Articles/977310/">https://lwn.net/Articles/977310/</a><br> </div> Sun, 23 Jun 2024 19:37:41 +0000 https://lwn.net/Articles/979427/ https://lwn.net/Articles/979427/ Kaligule <div class="FormattedComment"> Please, what is P4?<br> </div> Sun, 23 Jun 2024 17:48:42 +0000 https://lwn.net/Articles/979414/ https://lwn.net/Articles/979414/ Wol <div class="FormattedComment"> <span class="QuotedText">&gt; But I fear there's usually more resistance to change than just having to learn a new language or a new tool.</span><br> <p> It usually involves changing your entire way of thinking.<br> <p> Look at that post a few days back over P4 - where the comment was "someone comes along thinking they can rewrite it in C", and several man-years of effort later, they realise that actually, someone using a domain specific language can do double the work in half the time, if not even better.<br> <p> Going back even further, someone commented people who've learnt Rust usually make far better C programmers because, even though C doesn't enforce memory safety etc, because Rust insists that you code in memory-safe ways, they code memory-safe in C anyways.<br> <p> It's like me and databases - 4th normal form is the best for a whole bunch of reasons, but because my experience is with a database where 4th normal form was the OBVIOUS way to do it, when I'm forced to work with relational I do it without thinking. Unfortunately I'm usually working with stuff designed by others where I'm thinking "what the hell were they thinking?".<br> <p> Cheers,<br> Wol<br> </div> Sun, 23 Jun 2024 08:52:54 +0000 https://lwn.net/Articles/979410/ https://lwn.net/Articles/979410/ aszs <div class="FormattedComment"> Maybe I missed something but it didn't seem that the problem being discussed here was how to "verify that every filesystem conforms to the current VFS locking rules" but rather how to make sure the semantics of the Rust APIs for writing file systems match the semantics for the C APIs for writing file systems -- even as those semantics are changed developers that might ignore the Rust bindings. And if it's unrealistic to test all the ways a surface API might impact some internal invariant, well that's what fuzz testing is for. To be clear, I wasn't saying "just" write a test suite, I was saying I'm surprised tests aren't being discussed as part of a solution to a fairly hard problem.<br> <p> <p> <p> <p> </div> Sun, 23 Jun 2024 03:53:31 +0000 https://lwn.net/Articles/979390/ https://lwn.net/Articles/979390/ mathstuf <div class="FormattedComment"> One way would be to have some "token" ZST (zero-size type) that one could retrieve from any of these locking mechanisms. `folio_mark_dirty()` would then require that as one of its parameters. Something like:<br> <p> ```<br> let folio_lock = folio.lock();<br> let mark_dirty_allowed = folio_lock.i_want_to_mark_dirty();<br> <p> // …<br> <p> let buffer_head_lock = buffer_head.lock();<br> let mark_dirty_allowed = buffer_head_lock.i_want_to_mark_folio_dirty(&amp;folio)?; // better error handling, but checks that it is attached<br> <p> // ….<br> <p> let page_table_lock = page_table.lock();<br> let mark_dirty_allowed = page_table_lock.i_want_to_mark_folio_dirty(&amp;folio); // similar to above; make sure this page table maps the folio<br> ```<br> <p> Techniques from ghost_cell[1] can likely be used to ensure that the "mark_dirty_allowed" proof token is associated with the folio in question and not any folio that might also exist.<br> <p> [1] <a href="https://docs.rs/ghost-cell/latest/ghost_cell/">https://docs.rs/ghost-cell/latest/ghost_cell/</a><br> </div> Sat, 22 Jun 2024 20:06:42 +0000 https://lwn.net/Articles/979389/ https://lwn.net/Articles/979389/ willy <div class="FormattedComment"> How would you write a test suite that verifies that every filesystem conforms to the current VFS locking rules? Particularly when those locking rules are mostly not written down.<br> <p> To take an example that I do know...<br> <p> When you call folio_mark_dirty(), you must guarantee that the folio will not be concurrently truncated from the file (for values of truncate that include operations like hole-punch).<br> <p> Holding the folio lock is one way to do that. But this is a sleeping lock, so you can't always do that. If the folio is currently mapped by a page table, holding that page table lock guarantees truncation will not complete, and some callers rely on this.<br> <p> If you have buffer heads attached to the folio, and you have a buffer head locked, then that is also sufficient to prevent truncation. Some callers rely on this.<br> <p> Now, encode all that information into a type system? Not sure it can be done. And you certainly can't write a test suite for it. Or any reasonable assertion.<br> <p> I'm a huge fan of test suites. But saying "just write a test suite" without understanding the problem space is not helpful.<br> </div> Sat, 22 Jun 2024 18:41:27 +0000 https://lwn.net/Articles/979379/ https://lwn.net/Articles/979379/ aszs <div class="FormattedComment"> I'm a little surprised there's no mention here about building a test suite for these "complicated cases" -- that's the obvious way to make sure two independent implementations conform. And it has some benefits:<br> * the grunt work doesn't have to be done by time-constrained core developers<br> * getting a nice test suite out of this effort could be a good sweetener to motivate Rust-resistant maintainers<br> </div> Sat, 22 Jun 2024 15:17:39 +0000 https://lwn.net/Articles/979377/ https://lwn.net/Articles/979377/ adobriyan <div class="FormattedComment"> <span class="QuotedText">&gt; The only way to convince people to switch is to write more good Rust code, ultimately.</span><br> <p> Just imagine what bug-for-bug compatible Linux.rs kernel could do...<br> </div> Sat, 22 Jun 2024 14:21:44 +0000 https://lwn.net/Articles/979376/ https://lwn.net/Articles/979376/ khim <font class="QuotedText">&gt; It's the first language in 50 years to be enough of an advantage over C to be worth switching to.</font> <p>Sure, but the flip side is that it <b>is</b> the first language in 50 years that offers genuine advantage large enough to switch.</p> <p>The only way to convince people to switch is to write more good Rust code, ultimately.</p> Sat, 22 Jun 2024 14:05:59 +0000 https://lwn.net/Articles/979371/ https://lwn.net/Articles/979371/ atnot <div class="FormattedComment"> The thing that doesn't solve though, is how much information you lose going from Rust to C. That's somewhat improving with things like counted_by, but it's a long way off.<br> <p> However, even that ultimately doesn't really matter, because the barriers to calling Rust from C aren't primarily technical. It's more the attitude among some people that Rust for Linux is just a temporary blip that is bound to fail, or a hope that it does so you don't have to deal with it. Which becomes significantly harder if C code is allowed to call Rust.<br> <p> There will realistically be a pretty long tail of people who need a few more years to be convinced Rust is not going away, and probably not everyone will be. However I think writing C APIs in Rust will be a lot more palatable when, say, the GPU driver you are currently using being removed seems unwelcome enough that Rust is de facto necessary anyway. But it'll be a bit until that happens.<br> </div> Sat, 22 Jun 2024 13:52:16 +0000 https://lwn.net/Articles/979370/ https://lwn.net/Articles/979370/ liw <div class="FormattedComment"> If it were only a matter of teaching kernel hackers the Rust language, that'd be a solvable problem. (I say, as someone who does Rust training for free and for money.) But I fear there's usually more resistance to change than just having to learn a new language or a new tool.<br> </div> Sat, 22 Jun 2024 12:37:58 +0000 https://lwn.net/Articles/979369/ https://lwn.net/Articles/979369/ pbonzini <div class="FormattedComment"> What will _actually_ happen is a mix of three things:<br> <p> 1) APIs are changed in backwards-incompatible ways (e.g. <a href="https://www.spinics.net/lists/intel-gfx/msg349025.html">https://www.spinics.net/lists/intel-gfx/msg349025.html</a>) but they're generally not complicated and you handle them with topic branches as usual.<br> <p> 2) new APIs are introduced but updating 50 filesystems (or hundreds of anonymous file_operations) does not happen at ones, therefore in practice fallbacks are left in place and Rust bindings can be updated separately. The typical example here is read_iter/write_iter.<br> <p> 3) most subsystems that have Rust bindings will have no problem adjusting, at which point who's left will have to acknowledge the reality.<br> <p> </div> Sat, 22 Jun 2024 12:33:53 +0000 https://lwn.net/Articles/979367/ https://lwn.net/Articles/979367/ willy <div class="FormattedComment"> <a href="https://en.wikipedia.org/wiki/Planck%27s_principle">https://en.wikipedia.org/wiki/Planck%27s_principle</a><br> <p> "Science advances one funeral at a time"<br> <p> I'm disappointed by how resistant some fellow hackers are to Rust. It's the first language in 50 years to be enough of an advantage over C to be worth switching to.<br> </div> Sat, 22 Jun 2024 12:08:15 +0000 https://lwn.net/Articles/979359/ https://lwn.net/Articles/979359/ pizza <div class="FormattedComment"> <span class="QuotedText">&gt; Sometimes it's just easier to wait until older guys retire than to convince them to adapt to new way of doing things.</span><br> <p> Change, real change, has _always_ operated on a generational cycle.<br> <p> (And this isn't "adapt to the new way", it's "double your congnitive workload maintaining a mission-critical working system before its nominal replacement is ready to be deployed.")<br> </div> Sat, 22 Jun 2024 11:41:59 +0000 https://lwn.net/Articles/979357/ https://lwn.net/Articles/979357/ wsy <div class="FormattedComment"> Sometimes it's just easier to wait until older guys retire than to convince them to adapt to new way of doing things.<br> </div> Sat, 22 Jun 2024 10:54:35 +0000 https://lwn.net/Articles/979354/ https://lwn.net/Articles/979354/ gray_-_wolf <div class="FormattedComment"> This part has cought my eye:<br> <p> <span class="QuotedText">&gt; But Ts'o pointedly said that not everyone will learn Rust; if he makes a change, he will fix all of the affected C code, but, "because I don't know Rust, I am not going to fix the Rust bindings, sorry". </span><br> <p> I understand the view point, but I wonder how will this work with regards to the "do not break user space" policy. Let us say that Ts'o does some change, and updates all C users. But the Rust binding will break (either compilation, or runtime behavior). What now? In ideal world someone from rust-on-linux will step up and promptly resolve the issue. However we do not live in the ideal world and everyone has full plate already. What now? Will Ts'o's change be prevented from being merged? Will it be merged and the rust part just be broken (with user-space visible effects) until someone finds the time?<br> <p> On similar note, will contributors with less weight behind them have the same priviledge of saying "I am not touching rust code"?<br> <p> Regardless of my opinion on rust, this whole thing is really interesting experiment, so I am wondering what is current thinking in the community regarding this.<br> </div> Sat, 22 Jun 2024 10:41:40 +0000