Converting Linux's C code to Rust necessary?

Discussion
1

The push to convert Linux code from C to Rust to improve memory safety seems to be gaining momentum.

There is a far simpler solution that seems to have been neglected. You should read about CHERI CPU’s

The entire memory safety issue can be dealt with in hardware.
so
Why bother rewriting something like 15 billion lines of C code in another language, when all you need to do is change the CPU chip.?

In addition to that Rust is generally considered to be the most unreadable language ever invented… for example

https://medium.com/@lordmoma/ok-rust-you-really-have-a-readability-problem-e379df7df8df

and

They need to reread the immortal Donald Knuth

" Programs are meant to be read by humans and only incidentally for computers to execute."

and

" Programming is the art of telling another human being what one wants the computer to do."

I feel that the R4L push should be paused, and that Rust needs a complete redesign of its syntax.

Any opinions?

4 Likes
2

If it were that simple I’m sure someone would have thought of it by now. There are also advantages to rewriting the code base. You can clean out old crud that is never referenced and you can refine your technique for new ones. Refactoring.

2 Likes
3

I agree, but why not rewrite it in good readable C code.?
Going to a poorly designed language is a bad decision.
I am not the only one who thinks that Rust is unreadable.

People have a habit of ignoring the obvious alternative when they want to do something.
Using memory leaks as an argument for Rust is a flawed argument.

I also do not understand why finding memory leaks at compile time rather than at run time is such a big issue?
I have written C code using malloc() and have got my pointers wrong and had to debug ‘segmentation fault’ errors. It is not all that difficult… about the same as finding an overindexed array. If the compiler stopped me, I would still have to debug the same coding error.

2 Likes
4

It’s not just memory leaks. It’s use after free and other errors too. If it were possible for people to find and fix all the errors, we wouldn’t have all the vulnerabilities we do.

That is why it is better to use a language that is built specifically to avoid them in the first place. You CAN code an exception and perform unsafe memory operations in Rust. The idea is you don’t make it easy.

Everyone has their own opinion as to what is readable code. That’s fine. I don’t find Rust that much different that C. It is different for sure.

1 Like
5

I think I had better have a look at Rust, and understand what it does that prevents one making pointer errors.
It is not just pointers, you can overindex arrays too, but it should be able to check that easily in the compiler.

They are having a bet each way . If it is there, people will use it.

2 Likes
6

It is not a simpler solution, it would probably be the largest and most complex undertaking by humanity ever. You would need to construct at least hundreds of factories to produce enough CPUs to replace all exsistent ones (and each chip factory costs billions of dollars). Then you would need to have people who actually replace the CPUs, and all of it would need to be organized. We’re talking trillions if not quadrillions of dollars in cost.

If you did not do this, then it would be irrelevant because almost all CPUs in existence would not have the safety features you mentioned. Also, this is assuming that this thing actually works in the real world, which is the real rub.

I don’t think anyone who is actually serious has suggested all C code be replaced with Rust. Anyone who has suggested this you can safely ignore, they are of the same ilk who thinks in less than a year no humans will be programming anymore because AI will do all of it.

If nothing else, the extreme cost of replacing so much perfectly good code will mean it will not happen. In can see it in some cases for certain applications, which is mostly what is happening.

If you don’t like how Rust looks, that is a perfectly valid opinion. You’ve made it quite clear that you feel strongly about that. I took a glance at some Rust code and while I agree it is not exactly easy on the eyes, it is certainly not at “complete redesign” level.

It can be easy to fix these issues when the code base is small. But the code base is often not small. Look at the Linux kernel, which has roughly 40 millions lines of code. You have a use after free bug. Go find it. Good luck.

Keep in mind that for such large projects (and even medium projects), having some bugs is just unavoidable. Also, some bugs are worse than others. Memory leaks, use after free and other memory errors are some of the worst because they can be exploited to do remote code execution or gain an admin shell. So even if you were to trade bugs of this nature for other bugs, you would often take it.

2 Likes
7

Have people forgotten how to use debuggers.? You can trace these things.

Yeah, that is definitely an opinion. I cant convince everyone on that.

What I dislike is having type info mixed in with the control code. I think C with declarations in #include files makes for cleaner looking code.

Every language I have ever used has had stuff like declarations, definitions, formats,… either at the top or in separate files.
It is like when you are writing text… you dont put footnotes and references and other side issues inline… you move them out so the text reads clean

I wish they would rejig it. If we have to use Rust, then surely we can make it clean to read.

Well how do you choose which to replace? I think the supposed benefits with memory issues will disappear unless you replace all of it.

Nothing will happen with kernel code unless Linus approves.

Do you get Linux Magazine?
Read the editorial in the current issue( Apr 25).
There is a lot of ill feeling about Rust in the kernel team, and that is one group we can not afford to upset… we could lose good people.

I wish they would just put Rust out there and let people evaluate it and decide whether to use it… like most new languages.
The problems come when you start a project like this

and it becomes a political movement.
That irritates people.

1 Like
8

Some few weeks ago I watched on YouTube about this … the project leader left the distribution due this decision to move to Rust. The reason was not mentioned and I don’t remember what distro was

I think the best approach is work with two branches. Keep the same distribution built with C and bring/offer other with Rust. Therefore letting to each user use the classic and taste the new. The feedback and comparison are going to be more specific and valuable.

Of course it required more work but is safe and how was mentioned it helps to clean old code

1 Like
9

Although it not the solution just yet, but many a going down the route of nocode.

It asks the question with ai of it can generate it’s own code to replace c, r, rust etc. just like COBOL pascal basic etc were replaced. Ok not totally.

Personally I am not capable :pensive_face:

2 Likes
10

Interesting the page shared … thank you

Even when AI is there so far it can’t replicate the human experience about the learning curve :nerd_face:

1 Like
11

I think that would be a much better way to go about it.
Like Wayland and X11… the user can choose.

I think they are frightened of that approach… it hands power over to the users.

1 Like
12

OK for apps maybe, but not for kernel development.

1 Like
13

The changes proposed are segment by segment. The kernel is modular and only some of them are being considered for a Rust version. If it works great, if not it shouldn’t hurt a thing. If it turns out to be better or safer than the existing code, then it should “win”. If it isn’t, then maybe it won’t. Competition right?

1 Like
14

Yeah, but when do users get a vote.?
I think forking the kernel would be a better way.

1 Like
15

If they are going to act like that one guy, I say they deserve to be a little upset. He was basically throwing a tantrum and Linus himself called him out on it.

Now, I do know in that same conversation we had a Rust guy (I think he had something to do with Fedora Asahi Remix - e.g. Fedora for Apple Silicon Macs) who was also being quite unreasonable.

In the end, kernel development can only survive if people are going to act reasonable AND new people join. Some part of that is going to include the addition of new technologies, which will be necessary for the continued health of the kernel. Linus thinks that means that Rust should be used, primarily in stuff like drivers. In fact, the above mentioned argument was in the DMA part of the kernel, which specifically has to do with device drivers.

Oh, please. Debuggers, while they are useful tools cannot do everything for you. Something like the Linux kernel, which can be built and configured many different ways cannot be debugged for every scenario. Why? Because for any given part of the kernel, there are probably dozens of settings that can affect it, and when you combine this all together you get hundreds or thousands of them. You could probably test / debug the more used subset of these settings, provided you know what settings and why.

Unfortunately, you will still have to consider the edge cases, as the kernel is used so widely in so many different things. Those users are important too.

Again, if these problems were as easy to solve as you have made them out to be, they would’ve been solved long ago. Instead, they are some of the biggest and most widespread bugs in software.

I vote for Rust in the Linux kernel, at least in the current way it is being utilized.

I can understand why a lot of people see Rust as over-hyped, because honestly it has been. Sometimes, things are over-hyped for good reason. You don’t have people like Linus Torvalds, and companies like Microsoft, Google and Firefox pouring resources in Rust just because it is over-hyped. They think it will actually solve some real problems with software.

We’ve only seen Rust applied at a small scale for the most part, and it is just starting to be used on medium and large scale projects. It will be some time before we can fully render judgement if it does indeed solve the problems it is purported to solve, and any new problems with the ways it solves those problems are not worse than what they are solving. Early evidence points to the answer is “yes” though.

To be clear though, I don’t actually see Rust replacing C, at least not for a really really long time. I think C will at least still be in use when my grandchildren grow old, unless something really shakes everything up. Like quantum computing maybe? Even then I doubt it.

3 Likes
16

I think that is a really shrewd choice… there are a lot of problems with drivers… because they interact with the real world.

Oh yes, tools are not everything.
You need the mentality to think out possible scenarios, and you need Divide and Conquer to fence off the issue.
I do think old fashioned debugging skills are being lost… I may be wrong.

Jimmy, I think your reply is well considered and mostly right to the point. You do have quite a lot of development experience in teams. I am much more of a loner who will go off and do something different.
Thank you.

My own position on rust seems to be evolving into maybe learn a bit and see if I can grasp the new concepts.

3 Likes
17

Users don’t care if it is developed in C or Rust. Developers might. If it helps prevent some vulnerabilities, I’m all for it. I don’t have to look at the code as a user.

The kernel developer community is a tough one. Lots of responsibility. I think they, like most of us here, are aging. If we get younger people started in kernel development, it’ll likely be in Rust that runs alongside the existing C.

2 Likes
18

Are we risking things stopping working by trying to re write to fix something thats not broken… would it be better just to introduce new parts in the different language ?

So new printer driver or graphics card part not trying to eat the whole éléphant in one meal

2 Likes
19

We need young maintainers for existing C too?.

Yeah, or redo a particularly troublesome driver like Nvidia.

I wonder if there is a security holes aspect to this.? Can rust lead to more secure code? We dont want it opening up new ways to implant malware.

2 Likes
20

Here is a nice Reddit post about the same topic. Looks like it’s from one of the people working on the uutils conversion project.

https://www.reddit.com/r/linux/comments/1jjo1hv/a_tremendous_feature_of_open_source_software_is/?post_fullname=t3_1jjo1hv&post_index=4

The post references another blog. I’m reading that now.

1 Like