Linus Torvalds: Rust For The Kernel Could Possibly Be Merged For Linux 5.20

[ClosedSource]

Linux does not use semantic versioning. The major version changes when the minor gets too big for Linus' taste. All releases may break the kernel ABI, and none may break the userspace ABI.

Versioning is one thing I feel systemd/firefox/chrome got right. There isn't anything that particularly differentiates all 4.xx kernels from all 5.xx kernels from all 6.xx kernels.
Each kernel release seems to have enough changes to warrant a new major version number.

[Developer12]

I would think 6.0 should be the one that mandates rust support. That by itself would be a "breaking change" needing a new major version

There's nothing special about a major version of the linux kernel. There's no more difference between 4.9 and 5.0 than between 4.5 and 4.6. Linus merely rolls the major digit over whenever they hit 19-20 to avoid having linux x.20 getting confused with x.2 or some stupid reason like that.

As for mandating rust? Not even remotely going to happen. First there needs to be rust support for all the targets linux supports. Right now rust code can only be compiled using LLVM, which isn't even close. There's work on a GCC backend, but there's no way it'll be ready by the following kernel release.

[archkde]

Versioning is one thing I feel systemd/firefox/chrome got right. There isn't anything that particularly differentiates all 4.xx kernels from all 5.xx kernels from all 6.xx kernels.
Each kernel release seems to have enough changes to warrant a new major version number.

I'd agree, but for the opposite reason: the kernel, just like systemd, Firefox or Chromium (and GNU less, which is the oldest software I know of with this versioning scheme), adds new features slowly, in an evolutional fashion. At the end it doesn't really matter though as long as versions can be easily compared (so single number, calendar versioning and Linux' scheme all work, but Windows' marketing names not so much).

Semantic versioning is a very good idea for libraries and library-like software, but not really meaningfully applicable to anything else.

[luno]

It depends on what you are doing. Tokio is far from ideal for single threaded async. And not an option for microcontroller.

Some people asked on twitter about this https://twitter.com/fasterthanlime/s...34725185191937, can you explain more about why Tokio is far from ideal for single threaded async ?

[bug77]

It depends on what you are doing. Tokio is far from ideal for single threaded async. And not an option for microcontroller.

And that's exactly why async support cannot be in the standard library. Not to mention those cases where you do not want async at all.

[jacob]

The lack of language support for HKTs is also frustrating. You can kinda hack them in and somehow works, but it's far from ideal. I was hoping the likes of Amazon and Microsoft getting involved would speed things up, but sadly it seems a bit like Rust development has somewhat stagnated.

Rust develooment has certainly not stagnated, but I also wish it supported HKTs
However they were never announced as a priority or even a feature in development. At any rate GADTs are on their way and that covers pretty much the same needs.

[evasb]

There's nothing special about a major version of the linux kernel. There's no more difference between 4.9 and 5.0 than between 4.5 and 4.6. Linus merely rolls the major digit over whenever they hit 19-20 to avoid having linux x.20 getting confused with x.2 or some stupid reason like that.

As for mandating rust? Not even remotely going to happen. First there needs to be rust support for all the targets linux supports. Right now rust code can only be compiled using LLVM, which isn't even close. There's work on a GCC backend, but there's no way it'll be ready by the following kernel release.

It is highly probable that the Native GCC frontend is done enough in the beginning of 2023. I don't see why the extreme rush to merge rust support still in 2022.

[sinepgib]

Some people asked on twitter about this https://twitter.com/fasterthanlime/s...34725185191937, can you explain more about why Tokio is far from ideal for single threaded async ?

Not sure what OP means, but while "far from ideal" is something I have no clue about, it does not special case it, so everything it does to avoid races, deadlocks, etc, when running the runtime with multiple threads is still present when running a single one, i.e. you pay some extra overhead despite not having these issues.
You'd generally use an async runtime for two reasons:
1. It's enough for IO to be faster, and for that it's even more efficient than threading (that's why asyncio exists in Python, even tho CPython can't do multicore);
2. It's a nice abstraction to provide thread-per-core in the background (reducing OS scheduling overhead).

If you have only one core, you want a single thread, and you only use async for the case 1. But because of that your await calls should be sufficient synchronization (since otherwise you're already risking a deadlock).

[erniv2]

C code doesn't always gets turned into assembly, it just depends on the compiler

We disagree on that view.

Heeee ? Every high level language gets compiled to turn into assambler the machine language, thats what compilers are for, because nobody nowdays knows how to realy code assembler anymore, and even if it would take a horrible amount of time to write a simple programm in assembler, so i guess thats just not true. Thats why you also need multiple tools compiler truns it to assembler then the linker runs that code again and forms the actual binary wich then is just a jumbo mumbo of hex data, basically unreadable by a human being.

[sabian2008]

Heeee ? Every high level language gets compiled to turn into assambler the machine language, thats what compilers are for, because nobody nowdays knows how to realy code assembler anymore, and even if it would take a horrible amount of time to write a simple programm in assembler, so i guess thats just not true. Thats why you also need multiple tools compiler truns it to assembler then the linker runs that code again and forms the actual binary wich then is just a jumbo mumbo of hex data, basically unreadable by a human being.

Although I am not a programmer, I think he probably means that you might have C code which is irrelevant and hence the compiler when enabling optimizations might discard it at the IR level, effectively generating no Assembly code for that block of code.

He was probably being pedantic, like this whole discussion about whether Linux has one or two languages (and which in, btw, if you count Assembly, you probably have several different Assembly languages -- I imagine that all the supported micro-architectures must have at least a loader written in Assembly--).