Insulating layer?

Posted Oct 11, 2024 5:41 UTC (Fri) by tchernobog (guest, #73595)
In reply to: Insulating layer? by jkingweb
Parent article: On Rust in enterprise kernels

I also would welcome a more detailed explanation on this point.

I suspect it has to do with generics and Rust macros for the generation of large swats of serialization or other code in a type-safe manner, but I am not sure.

Insulating layer?

Posted Oct 11, 2024 7:03 UTC (Fri) by mmechri (subscriber, #95694) [Link] (2 responses)

I think this was briefly mentioned in a recent article: https://lwn.net/Articles/990736/

It seems like each firmware version may introduce changes that the driver must be able to deal with.

As a non-Rust developer, I would also be interested in learning how Rust makes it easier to deal with this.

Insulating layer?

Posted Oct 11, 2024 9:06 UTC (Fri) by k3ninho (subscriber, #50375) [Link]

I can't find the citation, but ISTR an Asahi Linux blog post about the macOS packages containing firmware updates, and the new firmware using arbitrary interfaces. This was a problem because an update can cause the same hardware to need different ABI layout to set it up appropriately. I think the text said there's code to solve this problem -- and in a Rust ecosystem, if only scripts and tooling.

K3n.

Insulating layer?

Posted Oct 11, 2024 10:37 UTC (Fri) by farnz (subscriber, #17727) [Link]

The big thing that Rust makes easier is writing performant code that's structured as "parse external form into suitable internal structures, work with internal structures, serialize into external form".

The type system then allows you to make sure that your invariants aren't ever broken inside the internal structures (absent the use of unsafe, which you can catch and worry about during code review). Rust enums (sum type) are powerful for representing choices, because enum variants can be structs, not just integers, while the affine typing rules Rust uses mean that you can guarantee that if someone wants to get an object of a specific type, they've given you ownership of an object of a different type, which allows you to prevent double-action of many forms (double-freeing is the famous one, but any form of double action on a type that shouldn't allow it is something you can prohibit).

Insulating layer?

Posted Oct 11, 2024 15:11 UTC (Fri) by jgg (subscriber, #55211) [Link]

The issue is that the FW ABI has a RPC based on a fixed layout struct like interface and NVIDIA re-organizes the struct randomly becauase they don't (yet?) care.

So imagine you have to make a function:

marshall_foo(int a, int b)

To produce the RPC struct to deliver to the FW.

Then FW version A has

struct foo_A {
u32 a;
u32 b;
};

And FW version B has

struct foo_B {
u32 c;
u64 a;
u32 b;
};

So, I can't say exactly what part of Rust is making this better. I've assumed it is built around generics to allow source code sharing and still robustly enforce the memory layout. However, any programming language has hard limits, it can't address semantic changes. In the above example you hope that 'c' can remain zero, and maybe have to deal with the reason 'a' got bigger.

Notice this is not about complex serializing or dynamic memory, or any of the other things rust is really strong at. Just knowing a giant table of offsets and sizes..

From a C perspective, I'd solve this class of problem with either a code generator or a multi-compilation scheme (similar to generics). iommu_pt and the MM are examples effectively solving a similar problem with non-semantic differences in page table entry memory layout, for instance.