How will fixing only C part work with the "do not break user space" policy? [LWN.net]

How will fixing only C part work with the "do not break user space" policy?

Posted Jun 22, 2024 12:33 UTC (Sat) by pbonzini (subscriber, #60935)
In reply to: How will fixing only C part work with the "do not break user space" policy? by gray_-_wolf
Parent article: Rust for filesystems

What will _actually_ happen is a mix of three things:

1) APIs are changed in backwards-incompatible ways (e.g. https://www.spinics.net/lists/intel-gfx/msg349025.html) but they're generally not complicated and you handle them with topic branches as usual.

2) new APIs are introduced but updating 50 filesystems (or hundreds of anonymous file_operations) does not happen at ones, therefore in practice fallbacks are left in place and Rust bindings can be updated separately. The typical example here is read_iter/write_iter.

3) most subsystems that have Rust bindings will have no problem adjusting, at which point who's left will have to acknowledge the reality.

to post comments

How will fixing only C part work with the "do not break user space" policy?

Posted Jun 25, 2024 8:42 UTC (Tue) by b7j0c (guest, #27559) [Link] (6 responses)

> What will _actually_ happen is a mix of three things:

treating the migration to Rust as inevitable feels like magical thinking, same as Mozilla experienced with Servo

How will fixing only C part work with the "do not break user space" policy?

Posted Jun 25, 2024 10:42 UTC (Tue) by pbonzini (subscriber, #60935) [Link] (5 responses)

I'm not talking of a full-scale migration; a non-trivial or undeniable level of adoption is enough.

How will fixing only C part work with the "do not break user space" policy?

Posted Jun 25, 2024 11:57 UTC (Tue) by pizza (subscriber, #46) [Link] (2 responses)

> I'm not talking of a full-scale migration; a non-trivial or undeniable level of adoption is enough.

In other words, "The inevitability of Rust becoming a requirement to build a usable/useful kernel."

...All it takes is one driver (not even subsystem), and *BAM* you're now a Rust system with a (substantial) pile of C.

(Or rather, "kernel-Rust" with a pile of "kernel-C")

How will fixing only C part work with the "do not break user space" policy?

Posted Jun 25, 2024 12:13 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

> > I'm not talking of a full-scale migration; a non-trivial or undeniable level of adoption is enough.

> In other words, "The inevitability of Rust becoming a requirement to build a usable/useful kernel."

Which, if the claims of the speed with which good solid drivers can be written in Rust are true, is inevitable sooner rather than later ...

I remember reading somewhere, that the speed at which a good programmer could produce good code was measured in LoC, REGARDLESS OF THE LANGUAGE USED. In other words, measured in terms an end user could understand - what a system could do - the choice of language has a major impact on productivity.

Cheers,
Wol

How will fixing only C part work with the "do not break user space" policy?

Posted Jun 25, 2024 17:20 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

> I remember reading somewhere, that the speed at which a good programmer could produce good code was measured in LoC, REGARDLESS OF THE LANGUAGE USED.

This is less surprising than it sounds. It basically amounts to "higher level languages allow programmers to write code that does more elaborate things in the same amount of development time," which had darned well better be true considering all of the performance cost of e.g. Python. If Python didn't give you a development speed advantage, there would be no (or at least much less) reason to use it for serious purposes (outside of the classroom).

How will fixing only C part work with the "do not break user space" policy?

Posted Jun 25, 2024 15:23 UTC (Tue) by b7j0c (guest, #27559) [Link] (1 responses)

both Microsoft and Google appear to be able to introduce Rust into existing codebases - but they also have the power to promote, deliver bonuses, or alternatively, fire people who aren't aligned with the strategy

open source projects are different...volunteers can just move on if they are unhappy, and if you don't have suitable replacement volunteers, things stop happening

How will fixing only C part work with the "do not break user space" policy?

Posted Jul 4, 2024 2:13 UTC (Thu) by mrugiero (guest, #153040) [Link]

That won't be a problem. Most kernel development is made by employees of companies with the ability to promote, deliver bonuses and firing, and they'd rather have their kernel maintained, be it in C, Rust or Pascal. You are right for the general case though, most open source projects are driven by volunteers. Linux is an exception to that rule.