Comment by braiamp

People keep misunderstanding it because the people who are shouting about how Rust is a terrible thing to have in the kernel keep claiming the situation is not that way.

I don't do mainline Linux dev regularly, I can't say whether the claim that Christoph made that the process doesn't actually work that way in practice is true or not without doing a lot of archaeology, but that's why there's confusion around it - because some people keep insisting that it doesn't work that way in reality. (At a 500 mile view, it seems like Linus going around making very explicit statements shutting down claims of that uncertainty a bunch would do wonders for clarity, but that assumes good faith on a lot of people's parts, and I also think Linus has learned not to be too visible in his proclamations about anything if he can avoid it...)

I do not believe that it will be possible for "the Rust for Linux team to step in and make whatever changes to the Rust code are needed", because that is much easier said than done.

With this rule that the Rust developers must maintain their own code, they are in the same situation like the maintainers of out-of-kernel device drivers.

I have maintained out-of-kernel Linux device drivers, so I know that this is a huge PITA. Almost every new Linux kernel minor version was breaking the device drivers, due to interface changes like: moving definitions from one Linux kernel header to another, adding or deleting parameters to functions, adding or deleting members to structures.

It is not enough to say that the Rust developers must maintain their own code, but it is also necessary for the responsibilities of the maintainers of the kernel subsystems written in C to be changed. Whoever changes an interface should also have the obligation to write a concise migration guide in which to explain what must be done to convert the invocations of the old interfaces into invocations of the new interfaces.

Only in this case the Rust developers would be able to maintain their code. Otherwise, they would have to bombard the C developers with questions after each change, which I assume is what Christoph Hellwig fears.

Such a requirement will increase the workload for the C developers, so I am not surprised that they are reluctant to accept users who will maintain their own code.

I have not checked recently the kernel documentation, but I doubt that anything has changed. When I was maintaining device drivers, every time when they became broken the only thing that could be done was to scan the kernel E-mail lists, to find who and why has changed the interface. This provided some context about the purpose of the changes, but there has never been any information about how to migrate the existing code to use the new interfaces.

When function arguments or structure members were deleted, it was simpler, one could delete them also in the device drivers hoping that they will continue to work. That did not work always, because sometimes additional new interfaces had to be invoked, to compensate for the simplification of the old interfaces.

Much worse was when function arguments or structure members were added, because only seldom it was possible to guess what values should be put in them.

In many cases the only solution was to waste a lot of time with reading the source for the entire subsystem whose interface had changed, in order to understand which were the effects of the interface changes.

All this was simple, but very tedious. What could have been done in a few minutes, had a migration guide existed, could require many hours of work in the absence of adequate documentation.

Unless the requirements for the documentation of the internal interfaces change, this is exactly what the Rust developers will also have to do, with the additional difficulty that they may be not very proficient at reading the kernel C language sources.

If there would be a clear requirement for the C maintainers to write a migration guide whenever they change interfaces, that would help not only the maintainers of Rust Linux device drivers, but also the maintainers of any out-of-kernel Linux device drivers.

However, there have been some Linux developers who not only did not make easy the maintaining of out-of-kernel device drivers, but who have made efforts to make as difficult as possible the maintaining of out-of-kernel device drivers, apparently due to some misguided belief that this will hurt some evil corporations.

In my experience, most out-of-kernel device drivers are for obsolete devices or for devices with very few users, whose maintenance is not sponsored by any corporation. So this behavior of actively making difficult the maintenance of out-of-kernel device drivers hurts mostly hobbyists, or at most small businesses, because they do not have the resources to push device drivers into the official tree.

> So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings.

I wasn't mistaken; this is exactly what I thought. The problem is that Rust developers aren't magical genies who you can summon to fix Rust code. In the real world they are volunteers who might be busy, on holiday, no longer interested, dead, etc. What do C maintainers do when the Rust genies don't magically appear and fix their code? Just break the Rust code? That's obviously not a good long term solution.

So while I totally disagree with the C developers - they should just learn Rust! - I don't think you can get around this point by just hand-waving "don't worry about it; someone else will fix the Rust code". Maybe in the very short term, but not in the medium term.

That's standard specially when a subsystem break other, you Cc them