4 ms·

I did, I'm actually puzzled he referenced this. You have a minority who wants to impose a change, and the concerns outlined in that video by the audience membe

I did, I'm actually puzzled he referenced this. You have a minority who wants to impose a change, and the concerns outlined in that video by the audience member reflects genuine concerns from many other maintainers and contributors. That this discussion repeats itself can only be taken to be either: 1) Evil C programmers are stodgy and old, and can't/won't get with the program, boo! 2) The Rust minority has, as of yet, failed to properly answer what happens when C APIs change in either signature or semantics, either of which can break the Rust bindings. Some questions: * Who tests to avoid this? * Who's expected to fix it? The one changing the C code, who might not know Rust or a separate bindings team? * Is there a process ? A person to contact/raise the issue with? To get help or to have the work done? * What happens if the bindings cannot be fixed in time for the next Kernel release? Put differently, will Rust bindings changes hold back changes to the C code? If broken bindings indeed can hold back changes, then C changes are held back by Rust and indeed then the onus is on the committer to either forego improving/evolving the C API or pick up Rust and fix the bindings also. In that case, yes, the Rust bindings will either freeze the C API or force the individual contributor to learn Rust. That people repeat their concerns isn't an expression of stupidity any more than a result of the people driving Rust into the kernel have yet to properly communicate how they envision this process to work, I suppose.

laerus 2y ago
Why the answers to these questions are not the same as if C code was calling other C code?
- pseudony 2y ago
  That should be obvious ? The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover. If I am contributing to the Linux kernel already, I presumably have a decent grasp of C, the central abstractions in the code I am changing, the email-based patch workflow and so on. So when my code breaks adjacent code, I should have a good chance of fixing those issues also, and most often, this won't become the main body of work. If jamming in Rust bindings means the great mass of existing contributors are forced to learn Rust, whether they wish or not, to either maintain bindings or to drop out altogether, then raising the pitchforks is not an unreasonable response.
  - Pet_Ant 2y ago
    > The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover. No, it just means that when their changes are ready, if they break the Rust bindings then then just need to fire off an email to the Rust people to update the binding. This is no different than having to get an approval before merging a branch. They don't have to code differently at all. It just slows down the merge. That's it.
    - steveklabnik 2y ago
      At present it doesn’t even slow down the merge! The whole point of the experiment is to get experience without interfering with the regular development of the kernel. It’s allowed to be broken by non-Rust work, and as you mentioned the Rust folks are wiling to do the work on that side.
  - laerus 2y ago
    Well then raise these concerns and find a way to solve them together. Not dismiss a proven solution to real and even dangerous problems like memory unsafety. It's unreasonable for educated grown men to react like 12yo children and resist change cause "we don't like eating our vegetables even though they are good for our health". If you actually care about the Linux kernel you will find a way forward even if that means communicating with people or even changing habits. At the end of the day I don't think that the people that are contributing to the Linux Kernel do it out of good will but rather more about than prestige and building a resume. Or else we wouldn't have this resistance to progress.
    - rc00 2y ago
      This is a horrible comment, much like many of the others on this thread. The long-time contributors to the Linux kernel project have been doing so before there was any "prestige" or resume credentials attached. And if it was just about a resume, wouldn't they have moved on already? This is an ill-conceived take and just another example of some of the pro-Rust crowd being far too unknowledgeable to be upset.
hazn 2y ago
i think we are arguing from different perspectives. my disgust of the video was the tone and hostility displayed by the linux maintainers. even though the presenter made it clear they came to learn and not to tell the C people how wrong their ways are, the linux maintainers kept on pouring. i understood your argument being a technical one, and not a social one. i have no opinion on this topic from the technical side.
- infamouscow 2y ago
  [flagged]
raggi 2y ago
A leader needs to draw a line in the sand around maintenance across changes. The discussions keep going back and forward on "I won't learn rust, so I won't do it" and "we can't have this anywhere real if it's going to be broken". There's no way to arbitrarily solve both of these issues, someone has to draw a line in the sand, say this is the goal everyone has to aim for, and tell everyone they're expected to collaborate. That doesn't mean everyone has to learn rust, nor does it mean rust should be perpetually broken. There needs to be a cut someday where rust becomes used in builds that are not "second class" anymore, and at that time, it will block releases. If that's not a goal, the whole project is pointless, so everyone has to get onboard with the goal, or explicitly say the project should be scrapped, then get on board with the leaders decision or withdraw from the discussion. Some of the minutae concerns were definitely valid, if a little disruptive in the conversation which could have been a bit more considerate but are ok and not too unusual for these summits. Ted was IMO extremely rude though. The tropes he came in with, and the tone, were disrespectful, trolly and rude, and they didn't offer any value whatsoever. Here's a breakdown: Opens with "we're almost out of time here" - aka, I'm gunna make a point, but we're not going to discuss it. Opening statement continued "I suspect part of the problem here is that you're trying to convince everyone to switch over to the religion as promulgated by rust". Kent certainly did spend probably too long talking _prior to examples_ about language features and how they avoid bugs. If they'd have said "here's an API we wrote and here's why we did it this way", that might have come across a little less preachy, but at no point did they actually get overly preachy, and this statement was born much more out of some other set of conversations or fears, and wasn't an appropriate reflection of what they'd been presenting or discussing _at all_. It was a direct challenge against their actions, but actions they hadn't taken, it's almost a personal attack. Ted closes that opener with "and the reality is that ain't gunna happen", which steps this opener which is already bordering on a personal attack into absolutism, dismissal and aggression. Opening statement still continued "because we have 50 plus filesystems and they will not all be instantly converted over to rust" - no one said or suggested anything of the sort, this is an absurd point and again is extremely disrespectful, because it implies they think otherwise, which is an absurd implication at this level - absurdity to the point of rude and insulting. Continuing still, Ted barely takes a breath, a strong indicator of excessive emotional content. "before that happens, we will continue to refactor the C code because we wanna make the C code better, if it breaks the rust bindings, at least for the foreseeable future, the rust bindings are a second class citizen and those filesystems that depend on the rust bindings will break and that is the rust bindings problem not the filesystem community at large problem, and that's gunna be true for a long long time". So yes, there's a central point in here which is a somewhat clear statement that the C devs won't fix rust, and rust will break in between. That's fine, everyone essentially agrees, and the thing is this is responding to, well, nothing that was presented, no one presenting said or implied otherwise. The trailing "for a long long time" though is heavily coded, and it combines with the earlier coded implication, the combination of which is: anyone who writes a filesystem in rust will be broken for a long long time. This is again extremely aggressive. If the statement was "until rust becomes a first class citizen" it's extremely reasonable, but that's not what was said, not at all, and given the totality of the tone you can confidently say this was intentional. This was a statement to onlookers "don't do this if you're serious", aka, don't do this. This statement is also closed with, much like the start of the opening remark "and we simply need to accept that", aka, this is as i have stated it and there shall be no more discussion. Cont. "the answer you're not allowed to refactor to the C code because it would break 5 critical filesystems that distros depend upon is like not a starter", well this isn't at all what he meant to say, he meant to say, and everyone took this as because it would break the rust bindings. Again this refers to some content that was not said in the presentation or the discussion. No one said the C couldn't be refactored. If we were to take the statement as stated, well, if there are 5 critical filesystems that distros depend on, regardless of what language they're implemented in, you don't get to just break them, and yeah, that's not a starter, this statement is useless content, everyone present knows Linux and Linus position on breaking userspace. Essentially this is pointless authority posturing, as it referred to none of the content under discussion. Part two, not that he stopped other than to breathe and set for the next statement, in fact someone started to respond and he spoke over them, continuing: "okay, we'll see, I suspect the best thing to do is you to continue maintaining your rust bindings over time there will be continued C code refactorings right, maybe we will start using kfree rcu, if that breaks rust, we will find out whether or not this concept of encoding huge amounts of semantics into the type system is a good thing, or a bad thing, and instead of trying to convince us what is actually correct, lets see what happens in a year or two and it will either work, or it wont and we will see, or more likely where does the pain get allocated because with most of these sorts of engineering things its almost always a pain allocation question" so again here more aggressive downtalk, again a time reference saying this is still going to be second class in a year or two, lots of emphasis on bad out outcome alternatives as they're stated clearly implying that this is all a bad path. There's so much misunderstanding here as well, there's not a lot of semantics they encoded into the type system, the method in question had split between a refcounted fully initialized type and an uninitialized type, this isn't crazy, and it is composable. Take the example of switching to kfree rcu, well the uninitialized type would be unaffected, and if rcu was integrated with the existing refcount type, well that wouldn't change either, so this code would be untouched, but if it took over the refcounting sure, the refcount type changes, but none of the implementation code. that's a pretty good outcome - in the C, well for this example you've gotta go look in the content of every caller of the equivalent C function, as noted and agreed through the discussion, as the semantics are encoded at each call site individually, and not reused or composed. A final note on the whole pain side of things, summing this all up it's essentially: here's a bunch of choices that maximize your pain, and if your path is the most painful "we'll see" aka you're toast. Again this is really unnecessarily threatening and rude, it's not a collaborative discussion, it's all downtalk and aggression, and the core points, well everyone knows the core points, so they didn't need to be said at all. Now the presenters respond, and they're just getting through saying "and while rust is a second class citizen i'm fine if you guys say i don't care about this you guys should look at it", and Ted jumps in, almost talking over the end of that sentence, clearly not hearing it, because he says "here's the thing" (now with a raised voice), "you're not gunna force all of us to learn rust, if i make a change, i will fix all of the c code because that's my responsibility, because i don't know rust i'm not gunna fix the rust bindings" then very sarcastically "sorry". He wasn't listening, he doesn't care to listen, he's angry, he wants these people gone, and well, per this article he got some of his way, but frankly this is disgusting, especially when you also consider Teds social weight. Repeatedly the actual ask that they had was "can you tell us where the semantics are", and implied "and when they change", and mostly what they got was gall and no actual response to those requests (from key actors). A few others did engage in good faith, and were asking what the semantics are of the Rust code and did offer some semantics inputs. I'm not sure who it was but the FS contributor who spoke a lot to the presenters on the way through, he, while interrupting most of the presentation for at least 15 of the 30 minutes, right at the end had essentially talked himself around to the function signature being pretty good. It'd have been nice if he did a bit more of that in his head, but I know the summits do tend to allow for a lot of this interrupty direct engagement, and so it's mostly within keeping, he took a lot of time but ultimately did engage somewhat productively.
simjnd 2y ago
> You have a minority who wants to impose a change, and the concerns outlined in that video by the audience member reflects genuine concerns from many other maintainers and contributors. What change exactly is being imposed? Rust has been accepted, so that parts of the kernel can be written in either Rust or C. Nobody is pushing for an entire kernel rewrite in Rust. Nobody is pushing out C maintainers. > The Rust minority has, as of yet, failed to properly answer what happens when C APIs change in either signature or semantics, either of which can break the Rust bindings. He answers in the very video: there is a process and it is communication. When a C API change which can break the Rust bindings, you email the maintainer responsible for the Rust bindings. It's as simple as that. > If broken bindings indeed can hold back changes, then C changes are held back by Rust and indeed then the onus is on the committer to either forego improving/evolving the C API or pick up Rust and fix the bindings also. In that case, yes, the Rust bindings will either freeze the C API or force the individual contributor to learn Rust. This is already happening with C development anyway, when an API change causes drivers maintained by different people to be updated, but nobody is saying "C changes are held back by C". > That people repeat their concerns isn't an expression of stupidity any more than a result of the people driving Rust into the kernel have yet to properly communicate how they envision this process to work, I suppose. But in this video, you see someone driving Rust into the kernel communicating how they envision this process to work, and a guy adopting a hostile tone claiming to be an engineer and calling another language a religion. This isn't concern, this is discrimination.
- abenga 2y ago
  > He answers in the very video: there is a process and it is communication. When a C API change which can break the Rust bindings, you email the maintainer responsible for the Rust bindings. It's as simple as that. This is a gross oversimplification. So after emailing, do you wait for the rust bindings to be fixed? Do you just get your changes merged regardless? Does the rust bindings maintainer have a say in what form your change takes? Can this hold back a release? > This is already happening with C development anyway,... As I understand it, the rule is if you change something that breaks other code, it is your responsibility to fix it (e.g. callers and such). This is obviously straightforward if you know C.

laerus 2y ago

Why the answers to these questions are not the same as if C code was calling other C code?

pseudony 2y ago
That should be obvious ? The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover. If I am contributing to the Linux kernel already, I presumably have a decent grasp of C, the central abstractions in the code I am changing, the email-based patch workflow and so on. So when my code breaks adjacent code, I should have a good chance of fixing those issues also, and most often, this won't become the main body of work. If jamming in Rust bindings means the great mass of existing contributors are forced to learn Rust, whether they wish or not, to either maintain bindings or to drop out altogether, then raising the pitchforks is not an unreasonable response.
- Pet_Ant 2y ago
  > The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover. No, it just means that when their changes are ready, if they break the Rust bindings then then just need to fire off an email to the Rust people to update the binding. This is no different than having to get an approval before merging a branch. They don't have to code differently at all. It just slows down the merge. That's it.
  - steveklabnik 2y ago
    At present it doesn’t even slow down the merge! The whole point of the experiment is to get experience without interfering with the regular development of the kernel. It’s allowed to be broken by non-Rust work, and as you mentioned the Rust folks are wiling to do the work on that side.
- laerus 2y ago
  Well then raise these concerns and find a way to solve them together. Not dismiss a proven solution to real and even dangerous problems like memory unsafety. It's unreasonable for educated grown men to react like 12yo children and resist change cause "we don't like eating our vegetables even though they are good for our health". If you actually care about the Linux kernel you will find a way forward even if that means communicating with people or even changing habits. At the end of the day I don't think that the people that are contributing to the Linux Kernel do it out of good will but rather more about than prestige and building a resume. Or else we wouldn't have this resistance to progress.
  - rc00 2y ago
    This is a horrible comment, much like many of the others on this thread. The long-time contributors to the Linux kernel project have been doing so before there was any "prestige" or resume credentials attached. And if it was just about a resume, wouldn't they have moved on already? This is an ill-conceived take and just another example of some of the pro-Rust crowd being far too unknowledgeable to be upset.

hazn 2y ago

i think we are arguing from different perspectives. my disgust of the video was the tone and hostility displayed by the linux maintainers. even though the presenter made it clear they came to learn and not to tell the C people how wrong their ways are, the linux maintainers kept on pouring. i understood your argument being a technical one, and not a social one. i have no opinion on this topic from the technical side.

infamouscow 2y ago
[flagged]

raggi 2y ago

A leader needs to draw a line in the sand around maintenance across changes. The discussions keep going back and forward on "I won't learn rust, so I won't do it" and "we can't have this anywhere real if it's going to be broken". There's no way to arbitrarily solve both of these issues, someone has to draw a line in the sand, say this is the goal everyone has to aim for, and tell everyone they're expected to collaborate. That doesn't mean everyone has to learn rust, nor does it mean rust should be perpetually broken. There needs to be a cut someday where rust becomes used in builds that are not "second class" anymore, and at that time, it will block releases. If that's not a goal, the whole project is pointless, so everyone has to get onboard with the goal, or explicitly say the project should be scrapped, then get on board with the leaders decision or withdraw from the discussion. Some of the minutae concerns were definitely valid, if a little disruptive in the conversation which could have been a bit more considerate but are ok and not too unusual for these summits. Ted was IMO extremely rude though. The tropes he came in with, and the tone, were disrespectful, trolly and rude, and they didn't offer any value whatsoever. Here's a breakdown: Opens with "we're almost out of time here" - aka, I'm gunna make a point, but we're not going to discuss it. Opening statement continued "I suspect part of the problem here is that you're trying to convince everyone to switch over to the religion as promulgated by rust". Kent certainly did spend probably too long talking _prior to examples_ about language features and how they avoid bugs. If they'd have said "here's an API we wrote and here's why we did it this way", that might have come across a little less preachy, but at no point did they actually get overly preachy, and this statement was born much more out of some other set of conversations or fears, and wasn't an appropriate reflection of what they'd been presenting or discussing _at all_. It was a direct challenge against their actions, but actions they hadn't taken, it's almost a personal attack. Ted closes that opener with "and the reality is that ain't gunna happen", which steps this opener which is already bordering on a personal attack into absolutism, dismissal and aggression. Opening statement still continued "because we have 50 plus filesystems and they will not all be instantly converted over to rust" - no one said or suggested anything of the sort, this is an absurd point and again is extremely disrespectful, because it implies they think otherwise, which is an absurd implication at this level - absurdity to the point of rude and insulting. Continuing still, Ted barely takes a breath, a strong indicator of excessive emotional content. "before that happens, we will continue to refactor the C code because we wanna make the C code better, if it breaks the rust bindings, at least for the foreseeable future, the rust bindings are a second class citizen and those filesystems that depend on the rust bindings will break and that is the rust bindings problem not the filesystem community at large problem, and that's gunna be true for a long long time". So yes, there's a central point in here which is a somewhat clear statement that the C devs won't fix rust, and rust will break in between. That's fine, everyone essentially agrees, and the thing is this is responding to, well, nothing that was presented, no one presenting said or implied otherwise. The trailing "for a long long time" though is heavily coded, and it combines with the earlier coded implication, the combination of which is: anyone who writes a filesystem in rust will be broken for a long long time. This is again extremely aggressive. If the statement was "until rust becomes a first class citizen" it's extremely reasonable, but that's not what was said, not at all, and given the totality of the tone you can confidently say this was intentional. This was a statement to onlookers "don't do this if you're serious", aka, don't do this. This statement is also closed with, much like the start of the opening remark "and we simply need to accept that", aka, this is as i have stated it and there shall be no more discussion. Cont. "the answer you're not allowed to refactor to the C code because it would break 5 critical filesystems that distros depend upon is like not a starter", well this isn't at all what he meant to say, he meant to say, and everyone took this as because it would break the rust bindings. Again this refers to some content that was not said in the presentation or the discussion. No one said the C couldn't be refactored. If we were to take the statement as stated, well, if there are 5 critical filesystems that distros depend on, regardless of what language they're implemented in, you don't get to just break them, and yeah, that's not a starter, this statement is useless content, everyone present knows Linux and Linus position on breaking userspace. Essentially this is pointless authority posturing, as it referred to none of the content under discussion. Part two, not that he stopped other than to breathe and set for the next statement, in fact someone started to respond and he spoke over them, continuing: "okay, we'll see, I suspect the best thing to do is you to continue maintaining your rust bindings over time there will be continued C code refactorings right, maybe we will start using kfree rcu, if that breaks rust, we will find out whether or not this concept of encoding huge amounts of semantics into the type system is a good thing, or a bad thing, and instead of trying to convince us what is actually correct, lets see what happens in a year or two and it will either work, or it wont and we will see, or more likely where does the pain get allocated because with most of these sorts of engineering things its almost always a pain allocation question" so again here more aggressive downtalk, again a time reference saying this is still going to be second class in a year or two, lots of emphasis on bad out outcome alternatives as they're stated clearly implying that this is all a bad path. There's so much misunderstanding here as well, there's not a lot of semantics they encoded into the type system, the method in question had split between a refcounted fully initialized type and an uninitialized type, this isn't crazy, and it is composable. Take the example of switching to kfree rcu, well the uninitialized type would be unaffected, and if rcu was integrated with the existing refcount type, well that wouldn't change either, so this code would be untouched, but if it took over the refcounting sure, the refcount type changes, but none of the implementation code. that's a pretty good outcome - in the C, well for this example you've gotta go look in the content of every caller of the equivalent C function, as noted and agreed through the discussion, as the semantics are encoded at each call site individually, and not reused or composed. A final note on the whole pain side of things, summing this all up it's essentially: here's a bunch of choices that maximize your pain, and if your path is the most painful "we'll see" aka you're toast. Again this is really unnecessarily threatening and rude, it's not a collaborative discussion, it's all downtalk and aggression, and the core points, well everyone knows the core points, so they didn't need to be said at all. Now the presenters respond, and they're just getting through saying "and while rust is a second class citizen i'm fine if you guys say i don't care about this you guys should look at it", and Ted jumps in, almost talking over the end of that sentence, clearly not hearing it, because he says "here's the thing" (now with a raised voice), "you're not gunna force all of us to learn rust, if i make a change, i will fix all of the c code because that's my responsibility, because i don't know rust i'm not gunna fix the rust bindings" then very sarcastically "sorry". He wasn't listening, he doesn't care to listen, he's angry, he wants these people gone, and well, per this article he got some of his way, but frankly this is disgusting, especially when you also consider Teds social weight. Repeatedly the actual ask that they had was "can you tell us where the semantics are", and implied "and when they change", and mostly what they got was gall and no actual response to those requests (from key actors). A few others did engage in good faith, and were asking what the semantics are of the Rust code and did offer some semantics inputs. I'm not sure who it was but the FS contributor who spoke a lot to the presenters on the way through, he, while interrupting most of the presentation for at least 15 of the 30 minutes, right at the end had essentially talked himself around to the function signature being pretty good. It'd have been nice if he did a bit more of that in his head, but I know the summits do tend to allow for a lot of this interrupty direct engagement, and so it's mostly within keeping, he took a lot of time but ultimately did engage somewhat productively.

simjnd 2y ago

> You have a minority who wants to impose a change, and the concerns outlined in that video by the audience member reflects genuine concerns from many other maintainers and contributors. What change exactly is being imposed? Rust has been accepted, so that parts of the kernel can be written in either Rust or C. Nobody is pushing for an entire kernel rewrite in Rust. Nobody is pushing out C maintainers. > The Rust minority has, as of yet, failed to properly answer what happens when C APIs change in either signature or semantics, either of which can break the Rust bindings. He answers in the very video: there is a process and it is communication. When a C API change which can break the Rust bindings, you email the maintainer responsible for the Rust bindings. It's as simple as that. > If broken bindings indeed can hold back changes, then C changes are held back by Rust and indeed then the onus is on the committer to either forego improving/evolving the C API or pick up Rust and fix the bindings also. In that case, yes, the Rust bindings will either freeze the C API or force the individual contributor to learn Rust. This is already happening with C development anyway, when an API change causes drivers maintained by different people to be updated, but nobody is saying "C changes are held back by C". > That people repeat their concerns isn't an expression of stupidity any more than a result of the people driving Rust into the kernel have yet to properly communicate how they envision this process to work, I suppose. But in this video, you see someone driving Rust into the kernel communicating how they envision this process to work, and a guy adopting a hostile tone claiming to be an engineer and calling another language a religion. This isn't concern, this is discrimination.

abenga 2y ago
> He answers in the very video: there is a process and it is communication. When a C API change which can break the Rust bindings, you email the maintainer responsible for the Rust bindings. It's as simple as that. This is a gross oversimplification. So after emailing, do you wait for the rust bindings to be fixed? Do you just get your changes merged regardless? Does the rust bindings maintainer have a say in what form your change takes? Can this hold back a release? > This is already happening with C development anyway,... As I understand it, the rule is if you change something that breaks other code, it is your responsibility to fix it (e.g. callers and such). This is obviously straightforward if you know C.