On Sat, 21 Oct 2023 13:05:59 +0000
Benno Lossin [off-list ref] wrote:

On 21.10.23 15:00, FUJITA Tomonori wrote:

quoted

On Sat, 21 Oct 2023 12:50:10 +0000
Benno Lossin [off-list ref] wrote:

quoted

quoted

quoted

quoted

quoted

I think this is very weird, do you have any idea why this
could happen?

DriverVtable is created on kernel stack, I guess.

But how does that invalidate the function pointers?

Not only funciton pointers. You can't store something on stack for
later use.

It is not stored on the stack, it is only created on the stack and
moved to a global static later on. The `module!` macro creates a
`static mut __MOD: Option<Module>` where the module data is stored in.

I know. The problem is that we call phy_drivers_register() with
DriverVTable on stack. Then it was moved.

I see, what exactly is the problem with that? In other words:
why does PHYLIB need `phy_driver` to stay at the same address?

phy_driver_register stores addresses that you passed.

This is an important requirement in Rust. Rust can ensure that
types are not moved by means of pinning them. In this case, Wedson's
patch below should fix the issue completely.

But we should also fix this in the abstractions, the `DriverVTable`
type should only be constructible in a pinned state. For this purpose
we have the `pin-init` API [2].

You can create DriverVTable freely. The restriction is what
phy_driver_register takes. Currently, it needs &'static DriverVTable
array so it works.

The C side uses static allocation too. If someone asks for, we could
loosen the restriction with a complicated implentation. But I doubt
that someone would ask for such.

Are there any other things in PHY that must not change address?

I don't think so.