openamp: add const for remoteproc_ops, image_store_ops and loader_ops

[xiaoxiang781216]

No description provided.

[arnopo]

Hello @xiaoxiang781216
Please could you split in 3 commits : lib, doc, app
Thanks,
Arnaud

[xiaoxiang781216]

Hello @xiaoxiang781216 Please could you split in 3 commits : lib, doc, app Thanks, Arnaud

doc can be split without error, but app can't pass the build independently. Do you still want to has some commit point can't pass the compile?

[arnopo]

Hello @xiaoxiang781216 Please could you split in 3 commits : lib, doc, app Thanks, Arnaud

doc can be split without error, but app can't pass the build independently. Do you still want to has some commit point can't pass the compile?

The point here is that the API is updated. So, even if it builds with success for OpenAMP examples this will not be the case for user project.
That said I did a test on my github and only warning seems generated due to the forced cast of a pointer to code to a pointer data

/github/workspace/apps/system/linux/machine/generic/platform_info.c:357:10: warning: initialization of ‘struct remoteproc * (*)(struct remoteproc *, const struct remoteproc_ops *, void *)’ from incompatible pointer type ‘struct remoteproc * (*)(struct remoteproc *, struct remoteproc_ops *, void *)’ [-Wincompatible-pointer-types]
1253
  357 |  .init = linux_proc_init,

But I suppose that depending on compilation options the warning could become an error.

So I still suggest making separate commits with an explicit commit message explaining the API update and its effect on project build.

Then concerning the API update itself, the disrupt is minor, and I would be OK to integrate if enough documented in commit message and release note.

@edmooring: what is your feeling on this?

[xiaoxiang781216]

Done.

[arnopo]

Look good to me.
The impact on API seems minor, but I would prefer to wait non regression test for release 2022.04 to evaluate impact on different platforms, before integrating it.

[edmooring]

Hello @xiaoxiang781216 Please could you split in 3 commits : lib, doc, app Thanks, Arnaud

doc can be split without error, but app can't pass the build independently. Do you still want to has some commit point can't pass the compile?

The point here is that the API is updated. So, even if it builds with success for OpenAMP examples this will not be the case for user project. That said I did a test on my github and only warning seems generated due to the forced cast of a pointer to code to a pointer data

/github/workspace/apps/system/linux/machine/generic/platform_info.c:357:10: warning: initialization of ‘struct remoteproc * (*)(struct remoteproc *, const struct remoteproc_ops *, void *)’ from incompatible pointer type ‘struct remoteproc * (*)(struct remoteproc *, struct remoteproc_ops *, void *)’ [-Wincompatible-pointer-types]
1253
  357 |  .init = linux_proc_init,

But I suppose that depending on compilation options the warning could become an error.

So I still suggest making separate commits with an explicit commit message explaining the API update and its effect on project build.

Then concerning the API update itself, the disrupt is minor, and I would be OK to integrate if enough documented in commit message and release note.

@edmooring: what is your feeling on this?

Agreed, including your later comment about testing. I will approve these changes so we can move forward.

On �a side note, we should probably bring this up at the steering committee, since these are technically API changes, but they are very minor. Does Zephyr have a policy for these kind of changes.

[edmooring]

Looks good to me.