Propose for meeting discussion

[xiaoxiang781216]

See here: rpmsg.pdf

[arnopo]

Hi @xiaoxiang781216,

1. RPMsg NS handcheck:
   Sorry for the latency, Bill seems busy and not found time yet for the meeting transcription.
   Anyway one conclusion was that the best way to relaunch the discussion is to resent a patch-set on Linux mailing list.
   As the conclusion was not clear I would propose 2 alternatives to relaunch the discussion on the Linux kernel mailing list

   • Resent the Linux patch after fixing the comments.
   • Or as discussions seems oriented on the fact that the ack should be initiate by the RPMSg service, rework it before to propose an API in rpmsg_ns

2. RPMsg buffer size
   We discussed this point in last OpenAMP meeting, seems that 2 points are missing in your patchset.

   • a negotiation phase (similar to what has been proposed in a previous [patchset from Loic Pallardy] (https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-610007)
   • to add version and feature-bit fields in the Virtio config structure, to ensure legacy compatibility.

I propose that we go by steps and start with the RPMsg NS handcheck.

[xiaoxiang781216]

Hi @xiaoxiang781216,

1. RPMsg NS handcheck:
   Sorry for the latency, Bill seems busy and not found time yet for the meeting transcription.
   Anyway one conclusion was that the best way to relaunch the discussion is to resent a patch-set on Linux mailing list.
   As the conclusion was not clear I would propose 2 alternatives to relaunch the discussion on the Linux kernel mailing list

   • Resent the Linux patch after fixing the comments.

Ok, I will do in the next couple week.

• Or as discussions seems oriented on the fact that the ack should be initiate by the RPMSg service, rework it before to propose an API in rpmsg_ns

After finishing the review, I will update to this approach if the community like this direction.

2. RPMsg buffer size
   We discussed this point in last OpenAMP meeting, seems that 2 points are missing in your patchset.

   • a negotiation phase (similar to what has been proposed in a previous [patchset from Loic Pallardy] (https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-610007)

The link describe "Packed virtqueues", is it really related to this feature? Could you give a link of Loic Pallardy's patchset?

• to add version and feature-bit fields in the Virtio config structure, to ensure legacy compatibility.

The patch alreay define feature-bit:
https://github.com/OpenAMP/open-amp/pull/155/files#diff-03144eb025fe729b04676264f230f5ba70dcb5151263c7ce17076b154a53c841R32

I don't add version field because virtio prefer to control the config space change by feature-bit. And the patch already reserve 64 bytes config space for the new feature-bit:
https://github.com/OpenAMP/open-amp/pull/155/files#diff-9291d1182b6a787e655aa22709b755704ae29f6f856fa737c420b7233cb64583R315-R321

I propose that we go by steps and start with the RPMsg NS handcheck.

Ok.

[arnopo]

• a negotiation phase (similar to what has been proposed in a previous [patchset from Loic Pallardy] (https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-610007)

The link describe "Packed virtqueues", is it really related to this feature? Could you give a link of Loic Pallardy's patchset?

Bad copy/past...
http://lkml.iu.edu/hypermail/linux/kernel/1703.3/02642.html

• to add version and feature-bit fields in the Virtio config structure, to ensure legacy compatibility.

The patch alreay define feature-bit:
https://github.com/OpenAMP/open-amp/pull/155/files#diff-03144eb025fe729b04676264f230f5ba70dcb5151263c7ce17076b154a53c841R32

Right, but this field is not related to the config struct only. The field would be used to interpret a muti configs structure.

I don't add version field because virtio prefer to control the config space change by feature-bit. And the patch already reserve 64 bytes config space for the new feature-bit:
https://github.com/OpenAMP/open-amp/pull/155/files#diff-9291d1182b6a787e655aa22709b755704ae29f6f856fa737c420b7233cb64583R315-R321

The version field is mainly to prevent an update of the structure itself that need to be known on both side.

[github-actions]

This issue has been marked as a stale issue because it has been open (more than) 45 days with no activity.