Rust support hits linux-next

Posted Mar 20, 2021 22:18 UTC (Sat) by adobriyan (subscriber, #30858)
In reply to: Rust support hits linux-next by stevenrwalter
Parent article: Rust support hits linux-next

> Are you saying you think there will be C++ in the kernel tree at some point?

I can't even push trivial stuff like renaming few "this" identifiers, so no.

> Also C++ is not source-compatible with C

C++ is maximally source compatible with C which automatically makes it the best
candidate for upgrading to a more capable programming language.

Trivial sources of source incompatibility come from casts and keywords
(people like plain "new" very much) but they can be scripted away.
I mean Googlers who posted Rust to linux-next are surely capable of it.

The most difficult sources of incompatibility don't come from C99 initialisers
(which can be rearranged) but from code like this:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...

If someone knows how C++ people deal with macrology/features above, please tell me.

Modules also have a _lot_ of icky macros as does tracing. I don't even want to think about it.

The biggest problem so far is g++ being so eager to shift compile time initialisation
to runtime. So far all oopses but one in my little Linux++ project were caused by this:
empty system call table, empty paravirt ops and empty protection_map[] array.

That one different oops was int/long confusion in ERR_PTR rewrite.

C99 caluse shuffling is very dangerous when rebasing. It is so easy to mismerge stuff and
omit or double init. Double init is tolerable because g++ complains but omission is silent.

Rust support hits linux-next

Posted Mar 20, 2021 22:24 UTC (Sat) by adobriyan (subscriber, #30858) [Link]

The best part was min/max rewrite. I liked it so much.

template<typename T, typename... Ts>
constexpr T min(T a, T b, Ts... etc)
{
	if constexpr (sizeof...(Ts) == 0) {
		return (a < b) ? a : b;
	} else {
		return min(min(a, b), etc...);
	}
}

Rust support hits linux-next

Posted Mar 21, 2021 4:00 UTC (Sun) by nyanpasu64 (guest, #135579) [Link] (1 responses)

> The biggest problem so far is g++ being so eager to shift compile time initialisation
> to runtime. So far all oopses but one in my little Linux++ project were caused by this:
> empty system call table, empty paravirt ops and empty protection_map[] array.

C++20 has the constinit keyword to enforce compile-time initialization of a data structure (designed to avoid the static initialization order fiasco), but I don't think it's coming to C anytime soon. I think it might solve your problem with gcc or g++, but I'm not confident.

Rust support hits linux-next

Posted Mar 22, 2021 15:02 UTC (Mon) by adobriyan (subscriber, #30858) [Link]

I don't think constinit as keyword helps. Asking C programmer to type "static const constinit ..." every time is too much and then there is confusion about double const and potential problem if const is omitted moving data from .rodata to .data section silently.

What's needed is compiler flag to disable dynamic initialisation or
equivalent of "nm vmlinux | grep -e _GLOBAL__sub_I_".
The latter would have saved me a lot of time. :-\

Rust support hits linux-next

Posted Mar 21, 2021 21:42 UTC (Sun) by moltonel (guest, #45207) [Link] (4 responses)

> C++ is maximally source compatible with C which automatically makes it the best candidate for upgrading to a more capable programming language.

This is debatable. Some very smart and knowledgeable Linux devs still give C++ a firm "No", while they're giving Rust a cautious "Maybe". You shouldn't ignore that hint.

Any tech shift needs a high gain-over-cost ratio. While the cost of enabling C++ build in a C project is indeed very low, the gains are (in Linux's case, and compared to Rust) not amazing either, and the inadvertent compatibility issues can negate a lot of the gains. Which leads to another counter-argument: being source-incompatible might actually be a good thing, as the clear demarcation between the C world and the Rust world could be more manageable than the fuzzy C/C++ demarcation.

The jury is still out on Linux-Rust, but Linux-C++ looks like a well-beaten dead horse.

Rust support hits linux-next

Posted Mar 22, 2021 11:10 UTC (Mon) by Wol (subscriber, #4433) [Link] (3 responses)

> This is debatable. Some very smart and knowledgeable Linux devs still give C++ a firm "No", while they're giving Rust a cautious "Maybe". You shouldn't ignore that hint.

We've had that discussion elsewhere. Linux needs a low-level language, and probably the best definition of such a language is "it doesn't give the optimiser many options". The linux devs don't like getting bitten by optimisations where the compiler "assumes facts not in evidence", and C++ adds far too many features that enable exactly that.

I gather Rust has been designed as a low-level language, and as such is currently much better than C, which has steadily been acreting hi-level features. That's not to say it'll *stay* a low-level language, but at present Rust is actually probably a far better language than C for system-level programming.

Cheers,
Wol

Rust support hits linux-next

Posted Apr 27, 2021 14:25 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

> I gather Rust has been designed as a low-level language, and as such is currently much better than C, which has steadily been acreting hi-level features.

That's a fairly ridiculous characterization. By any standard, Rust is much higher-level than C: you name it, language-wise it has way more advanced features and permits a higher level of abstraction than C does. What it also has is more consistency (fewer implementation-defined edge cases).

Rust support hits linux-next

Posted Apr 27, 2021 16:21 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

But does it also provide more control over the machine code that's generated?

I've come to the conclusion that a good low-level language "does not give the compiler much opportunity to optimise well-written code". It seems most problems with C (for the kernel at least) are caused by the compiler optimising the hell out of it.

So long as high-level constructs map cleanly to the obvious underlying machine/assembler code, I'd call that a "good low-level language".

Cheers,
Wol

Rust support hits linux-next

Posted Apr 27, 2021 17:01 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Depends on who you ask I guess. Is it "clear" when a chain of iterator calls are fused into a single loop over the input? Is it "clear" when tail call optimization is applied? I couldn't tell you what instructions any given line compile down to in Rust or C myself anyways, so for me none of it is "clear" anyways.

That said, I don't know Rust's guarantees around reordering statements, but given the more explicit "I'm using a single variable across threads" model, there are likely a lot fewer ways the compiler can think to order things (barring bugs in the compiler, but that's C's problem too).

Rust support hits linux-next

Posted Mar 22, 2021 0:30 UTC (Mon) by flussence (guest, #85566) [Link] (1 responses)

> C++ is maximally source compatible with C which automatically makes it the best
> candidate for upgrading to a more capable programming language.

Objective-C would be a much better candidate by that criteria.

Rust support hits linux-next

Posted Mar 22, 2021 15:17 UTC (Mon) by adobriyan (subscriber, #30858) [Link]

I don't know Objective-C. How big is the flag day patch? The one which contains the following chunk:

-CC		= $(CROSS_COMPILE)gcc
+CC		= $(CROSS_COMPILE)g++