Comments by "" (@grokitall) on "Linus Torvalds Threatens To REMOVE This File System" video.

looks a lot like rust in the kernel, not playing well with others. the solution for both is simple. do the work by themselves outside the mainline, and as bits stabilise or need to update other parts of the kernel you get someone who can play nice specifically to work on getting that code from where it works and is stable to where it is in a shape that upstream is happy with. thats how the real-time branch got upstreamed, so it can work just as well for rust and bcachefs.
10
@KoopstaKlicca they are two sides of the same coin. in the case of kent and his codevelopers it is exactly as you describe. in the case of rust in the kernel, there is a set of work to be done, and major disputes as to the cost and who is going to pay it, with the rust developers thinking it is minimal and wanting the maintainers to pay, while the maintainers think it is significant, and want the rust guys to do it. in both cases it is some project which on the kernel scale is relatively minor thinking that most of the playing well with others should be done by the kernel maintainers adapting to the needs of their project, with the maintainers resisting. note: i am not saying all the rust in the kernel developers are like this, just enough of them to be harming their own case.
9
@tfemby just because it is working c code, does not make it good code, and even good code is possibly not done in the best way to be compatible. i can think of a number of patch sets written in c which had further work done on top of them out of tree, where it took up to 20 reworks to get to the point where it was right and good enough to merge, and even then they had to then start working to get the extra stuff they built on top upstreamed. just because you wrote something that you think is great (and you might even be right) does not give you the automatic right to have it merged into someone else's project. the real time kernel work was out of tree for 20 years, working to move code from their patched fork into the main line, and every small patch that made it in made the fork easier to maintain. but it did take time and rework to get it in. this is a point kent at bcachefs does not seem to get, and he expects every change to just be accepted right away, turning main line into an experimental kernel, which is why he has the current problems.
4
@kuhluhOG yes lifetimes exist in every language, but rust seems to need them to be known at api definition time for every variable mentioned in those apis, unlike just about every other language. when you put this constraint on another language just to get your type system to work, it does not come for free. i do not doubt that it is possible to write kernel code in rust, nor do the c maintainers, in fact some people are writing a kernel in rust, and good luck to them. people are also writing code for the kernel, but when you can't even get a stable compiler to work and need to download the nightly builds to get the code to even compile (according to one of the compiler devs st a rust conference), and you need an unspecified amount of extra work to even be able to start doing work on the unstable internal apis, there naturally arises the question of how much work and who has to do it. as to the problem with the drm subsystem, i've not seen the thread, so i don't know if it was done as a discussion around "this variable is used this way here and an incompatible way there", or if they just went and fixed the more problematical one for them to work in the way that made it easier for the rust developers, and then did a big code dump with little prior discussion. if it is the second case, it is the same issue of not playing well with others except on your own terms, and the resulting problems are deserved. if it is the first, then the issue should be raised on the usual channels, and initial patches proposed, with ongoing work to figure out if those patches are the best fix to the identified problems, just like with any other c developer. i just don't have enough context to determine if it was the rust devs, the c maintainers, or both talking past each other, and thus do not have a right to an opinion on the details i do not know.
3
@marcogenovesi8570 no, i mean the subset of rust developers who think that searching for things like lifetimes and other things not a part of c is trivial, but are unwilling to do it themselves, then want to throw the code over the wall into the kernel and then want the kernel maintainers to do the work maintaining it (even th9se who don't know rust). very like the way that the kdbus people could not be bothered to do the work to speed up dbus, and just expected to throw the existing api into the kernel and hand the problem over to the kernel folks. this is not just about kent, but is a bigger problem of relatively minor developers thinking that they can work in their sandbox, and when they think the code 8s ready, just dump it on the kernel maintainers, who also have to do the work to make the kernel ready for their code dump and maintain it later.
2
@roundduckkira kent is a major problem for kent, but not all code that works gets accepted. what is the reason for rejections? not accepting that there is a problem. not liking the proposed solution? a large set of patches all dropping in o e big merge? the patches arriving late in the merge cycle? none of these is the maintainer being deliberately awkward, and all can have valid reasons for not accepting the merge. they all have responses which can be made to get them merged eventually. not having seen the threads, i can't tell if it is problems with the maintainers, if the developers are just feeling entitled and then butthurt because their code was not just immediately taken without comment, or if it is members of the two communities talking past each other.
2
@VoicesInDark i would strongly disagree with the idea that kernel developers are replaceable, as most of the are doing critical work in important but obscure areas of development. as for them getting paid, so what if some company wants to pay them, with the idea of basically putting bug bounties on problems affecting their company. you still have a number of kernel contributors who are not tied to big companies. as to it being a community or not, i don't see any way you can define that word which would not cover 15,000 people trying to not get in each others way for years. if you mean the kernel project not being community driven like centos used to be and rocky is now, very few large projects or distributions fit that model. it certainly does not fit how systemd is developed, nor the kernel, and not gnome either.
2
@MikkoRantalainen kent obviously has an out of tree fork of the kernel where he does the development work, which is fine, and is where his current behaviour is heading. what he needs is someone else to work on upstreaming the code in small patches, doing rework to make the working code compatible with the rest of the code in the kernel. if he runs it like the real time patches project did, improvements can be made on his tree, while someone else manages reducing the delta between his tree and upstream, eventually getting his code into mainline. note: linus did not say no more bcachefs, only no more kent, and whoever takes over upstreaming needs to play well with the rest of the kernel developers..
2
@marcogenovesi8570 if you mean the rust developers expecting the maintainers to go and hunt up a lot of extra semantic information not neded in c just to comply with rusts expensive typing system, and calling it documentation, that is one aspect of it. when you choose to work in a different language, which has tighter requirements, you make building the language api bindings harder. that is fine, but then you have to be prepared to do the work to find that estraminformation, and only after you think you have got it right do you get to call requesting confirmation documentation. this happened with the ssl project in debian, where the person who initially wrote the code was not the person who provided the clarification, resulting in a major security hole, but the patch developers did the work and asked is it case a or case b, and got the wrong answer back because the answer is not always obvious. this is why the c maintainers push back at the claims that it is just documenting the api, and it is cheap, when it is neither. like with kent, and some of the systemd developers, the issue is not the language the code is being developed in, but the semantic mismatch between the information needed by the existing work, and potential ambiguities relating to how people want to use the existing apis in a different way to how they are currently being used, which might require disambiguation, which might require digging around in the code base and mailing lists to see if a close enough use case came up in potentially thousands of posts in the discussion to clarify the new semantics for the previously unconsidered use case. the time for them to do this is at merge time if there is an issue, not all upfront because it is just documentatiron. the general principal in most code bases is that if you want to create new code, go for it, but when you want to merge it with the existing mainline code base, do it in small separate chunks and be prepared to do the extra work to not just get it working, but to move it to a shape that is compatible with the main code base, and if it is more than a drive by bug fix, expect to stick around and be prepared to do a lot of the maintainance yourself. this goes double if you are working in a different language than the maintainers. otherwise, it eventually gets treated as unmaintained code, and deprecated prior to removal. again, it comes down to respecting the existing development process, being willing to work within it, and if you need minor changes to that process to make the work easier for both sides, working within the existing change process to gradually move the standard way of doing things in the desired direction, while bearing in mind that in the kernel there are 15000 other people whose direction does not necessarily match yours. kent does not get this, so i see his code getting booted unless someone who does steps up to maintain it. the systemd guys did not get it either, which is why kdbus went nowhere, after getting a lot of push back from lots of kernel maintainers. a significant subset of the rust in the kernel developers don't seem to get it either, harming their case and making things harder for their codevelopers. this problem is not confined to the kernel. middleware developers like systemd, gtk, wayland, and others seem to forget that it is not just their pet project, and that in the case of middleware they not only have the same problems as the kernel, with new developers having to play nice with their rules, but as someone with other communities involved, they also need to play nice with those below them, and not cause too many problems for those above them in the stack.
1
@alexisdumas84 i am not suggesting that every rust dev wants the maintainers to do everything, only that those who don't are being conspicuous in their absense with dissenting opinions or are failing to see how their additional semantic requirements to get the type system to work cause a semantic mismatch between what information is needed to do the work, and when. for c, it comes when the patch is finished and you try and upstream it, at which time any such problems result in considerable rework to get from working code to compatible code. this is why the real time patch set took nearly 20 years to get fully integrated into the mainline. for rust, all this work seems to need to be done upfront to get the type system to work in the first place. this is a major mismatch, and the language is too new and unstable for the true costs of this to be well known and understood. rust might indeed be as great as the early adopters think, with minimal costs for doing everything through the type system as some suggest, but there is an element of jumping the gun in the claims due to how new the language is. python 3 did not become good enough for a lot of people until the .4 release, and for others until the .6 release. as you maintain your out of tree rust kernel, with any c patches needed to make it work, have fun, just make sure that when it comes time to upstream the maintainers need to be able to turn on a fresh install of whatever distro they use, do the equivalent of apt get install kernel tools, and then just build the kernel with your patches applied. it is not there yet, and thus some code will stay in your out of tree branch until it is.
1
@marcogenovesi8570 they do document them to the extent needed to do development work in c (in most cases), but the rust developers need even more information which the c developers don't need until it is time to upstream a patch, and an actual problem occurs, not just the potential problems the rust compiler finds. its like having ai find bugs. yes it can do it, but it cannot work out if it is a bug, a threat, or an exploit.
1