Propose for meeting discussion #271

Activity

1. arnopo commented on Mar 26, 2021

   

   arnopo

   on Mar 26, 2021

   Collaborator

   More actions

   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.
2. xiaoxiang781216 commented on Mar 28, 2021

   

   xiaoxiang781216

   on Mar 28, 2021

   CollaboratorAuthor

   More actions

   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.
3. arnopo commented on Mar 29, 2021

   

   arnopo

   on Mar 29, 2021

   Collaborator

   More actions

   • 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.
4. github-actions commented on Oct 23, 2023

   

   github-actionsBot

   on Oct 23, 2023

   More actions

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

   added

   Stale

   on Oct 23, 2023