Re: [PATCH net-next v1 1/3] vm_sockets: Include flag field in the vsock address data structure
On 03/12/2020 15:38, Stefano Garzarella wrote: On Thu, Dec 03, 2020 at 12:32:08PM +0200, Paraschiv, Andra-Irina wrote: On 03/12/2020 11:21, Stefan Hajnoczi wrote: On Tue, Dec 01, 2020 at 05:25:03PM +0200, Andra Paraschiv wrote: vsock enables communication between virtual machines and the host they are running on. With the multi transport support (guest->host and host->guest), nested VMs can also use vsock channels for communication. In addition to this, by default, all the vsock packets are forwarded to the host, if no host->guest transport is loaded. This behavior can be implicitly used for enabling vsock communication between sibling VMs. Add a flag field in the vsock address data structure that can be used to explicitly mark the vsock connection as being targeted for a certain type of communication. This way, can distinguish between nested VMs and sibling VMs use cases and can also setup them at the same time. Till now, could either have nested VMs or sibling VMs at a time using the vsock communication stack. Use the already available "svm_reserved1" field and mark it as a flag field instead. This flag can be set when initializing the vsock address variable used for the connect() call. Signed-off-by: Andra Paraschiv --- include/uapi/linux/vm_sockets.h | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h index fd0ed7221645d..58da5a91413ac 100644 --- a/include/uapi/linux/vm_sockets.h +++ b/include/uapi/linux/vm_sockets.h @@ -114,6 +114,22 @@ #define VMADDR_CID_HOST 2 +/* This sockaddr_vm flag value covers the current default use case: + * local vsock communication between guest and host and nested VMs setup. + * In addition to this, implicitly, the vsock packets are forwarded to the host + * if no host->guest vsock transport is set. + */ +#define VMADDR_FLAG_DEFAULT_COMMUNICATION 0x + +/* Set this flag value in the sockaddr_vm corresponding field if the vsock + * channel needs to be setup between two sibling VMs running on the same host. + * This way can explicitly distinguish between vsock channels created for nested + * VMs (or local communication between guest and host) and the ones created for + * sibling VMs. And vsock channels for multiple use cases (nested / sibling VMs) + * can be setup at the same time. + */ +#define VMADDR_FLAG_SIBLING_VMS_COMMUNICATION 0x0001 vsock has the h2g and g2h concept. It would be more general to call this flag VMADDR_FLAG_G2H or less cryptically VMADDR_FLAG_TO_HOST. I agree, VMADDR_FLAG_TO_HOST is more general and it's clearer that is up to the host where to forward the packet (sibling if supported, or whatever). Ok, then VMADDR_FLAG_TO_HOST it is. :) I also updated the commit messages / comments to reflect this more general angle, with one of the current use cases being guest to guest communication. Thanks, Andra Thanks for the feedback, Stefan. I can update the naming to be more general, such as "_TO_HOST", and keep the use cases (e.g. guest <-> host / nested / sibling VMs communication) mention in the comments so that would relate more to the motivation behind it. Andra That way it just tells the driver in which direction to send packets without implying that sibling communication is possible (it's not allowed by default on any transport). I don't have a strong opinion on this but wanted to suggest the idea. Stefan Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
Re: [PATCH net-next v1 1/3] vm_sockets: Include flag field in the vsock address data structure
On Thu, Dec 03, 2020 at 12:32:08PM +0200, Paraschiv, Andra-Irina wrote: On 03/12/2020 11:21, Stefan Hajnoczi wrote: On Tue, Dec 01, 2020 at 05:25:03PM +0200, Andra Paraschiv wrote: vsock enables communication between virtual machines and the host they are running on. With the multi transport support (guest->host and host->guest), nested VMs can also use vsock channels for communication. In addition to this, by default, all the vsock packets are forwarded to the host, if no host->guest transport is loaded. This behavior can be implicitly used for enabling vsock communication between sibling VMs. Add a flag field in the vsock address data structure that can be used to explicitly mark the vsock connection as being targeted for a certain type of communication. This way, can distinguish between nested VMs and sibling VMs use cases and can also setup them at the same time. Till now, could either have nested VMs or sibling VMs at a time using the vsock communication stack. Use the already available "svm_reserved1" field and mark it as a flag field instead. This flag can be set when initializing the vsock address variable used for the connect() call. Signed-off-by: Andra Paraschiv --- include/uapi/linux/vm_sockets.h | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h index fd0ed7221645d..58da5a91413ac 100644 --- a/include/uapi/linux/vm_sockets.h +++ b/include/uapi/linux/vm_sockets.h @@ -114,6 +114,22 @@ #define VMADDR_CID_HOST 2 +/* This sockaddr_vm flag value covers the current default use case: + * local vsock communication between guest and host and nested VMs setup. + * In addition to this, implicitly, the vsock packets are forwarded to the host + * if no host->guest vsock transport is set. + */ +#define VMADDR_FLAG_DEFAULT_COMMUNICATION 0x + +/* Set this flag value in the sockaddr_vm corresponding field if the vsock + * channel needs to be setup between two sibling VMs running on the same host. + * This way can explicitly distinguish between vsock channels created for nested + * VMs (or local communication between guest and host) and the ones created for + * sibling VMs. And vsock channels for multiple use cases (nested / sibling VMs) + * can be setup at the same time. + */ +#define VMADDR_FLAG_SIBLING_VMS_COMMUNICATION 0x0001 vsock has the h2g and g2h concept. It would be more general to call this flag VMADDR_FLAG_G2H or less cryptically VMADDR_FLAG_TO_HOST. I agree, VMADDR_FLAG_TO_HOST is more general and it's clearer that is up to the host where to forward the packet (sibling if supported, or whatever). Thanks, Stefano Thanks for the feedback, Stefan. I can update the naming to be more general, such as "_TO_HOST", and keep the use cases (e.g. guest <-> host / nested / sibling VMs communication) mention in the comments so that would relate more to the motivation behind it. Andra That way it just tells the driver in which direction to send packets without implying that sibling communication is possible (it's not allowed by default on any transport). I don't have a strong opinion on this but wanted to suggest the idea. Stefan Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
Re: [PATCH net-next v1 1/3] vm_sockets: Include flag field in the vsock address data structure
On 03/12/2020 11:21, Stefan Hajnoczi wrote: On Tue, Dec 01, 2020 at 05:25:03PM +0200, Andra Paraschiv wrote: vsock enables communication between virtual machines and the host they are running on. With the multi transport support (guest->host and host->guest), nested VMs can also use vsock channels for communication. In addition to this, by default, all the vsock packets are forwarded to the host, if no host->guest transport is loaded. This behavior can be implicitly used for enabling vsock communication between sibling VMs. Add a flag field in the vsock address data structure that can be used to explicitly mark the vsock connection as being targeted for a certain type of communication. This way, can distinguish between nested VMs and sibling VMs use cases and can also setup them at the same time. Till now, could either have nested VMs or sibling VMs at a time using the vsock communication stack. Use the already available "svm_reserved1" field and mark it as a flag field instead. This flag can be set when initializing the vsock address variable used for the connect() call. Signed-off-by: Andra Paraschiv --- include/uapi/linux/vm_sockets.h | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h index fd0ed7221645d..58da5a91413ac 100644 --- a/include/uapi/linux/vm_sockets.h +++ b/include/uapi/linux/vm_sockets.h @@ -114,6 +114,22 @@ #define VMADDR_CID_HOST 2 +/* This sockaddr_vm flag value covers the current default use case: + * local vsock communication between guest and host and nested VMs setup. + * In addition to this, implicitly, the vsock packets are forwarded to the host + * if no host->guest vsock transport is set. + */ +#define VMADDR_FLAG_DEFAULT_COMMUNICATION 0x + +/* Set this flag value in the sockaddr_vm corresponding field if the vsock + * channel needs to be setup between two sibling VMs running on the same host. + * This way can explicitly distinguish between vsock channels created for nested + * VMs (or local communication between guest and host) and the ones created for + * sibling VMs. And vsock channels for multiple use cases (nested / sibling VMs) + * can be setup at the same time. + */ +#define VMADDR_FLAG_SIBLING_VMS_COMMUNICATION 0x0001 vsock has the h2g and g2h concept. It would be more general to call this flag VMADDR_FLAG_G2H or less cryptically VMADDR_FLAG_TO_HOST. Thanks for the feedback, Stefan. I can update the naming to be more general, such as "_TO_HOST", and keep the use cases (e.g. guest <-> host / nested / sibling VMs communication) mention in the comments so that would relate more to the motivation behind it. Andra That way it just tells the driver in which direction to send packets without implying that sibling communication is possible (it's not allowed by default on any transport). I don't have a strong opinion on this but wanted to suggest the idea. Stefan Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
Re: [PATCH net-next v1 1/3] vm_sockets: Include flag field in the vsock address data structure
On Tue, Dec 01, 2020 at 05:25:03PM +0200, Andra Paraschiv wrote: > vsock enables communication between virtual machines and the host they > are running on. With the multi transport support (guest->host and > host->guest), nested VMs can also use vsock channels for communication. > > In addition to this, by default, all the vsock packets are forwarded to > the host, if no host->guest transport is loaded. This behavior can be > implicitly used for enabling vsock communication between sibling VMs. > > Add a flag field in the vsock address data structure that can be used to > explicitly mark the vsock connection as being targeted for a certain > type of communication. This way, can distinguish between nested VMs and > sibling VMs use cases and can also setup them at the same time. Till > now, could either have nested VMs or sibling VMs at a time using the > vsock communication stack. > > Use the already available "svm_reserved1" field and mark it as a flag > field instead. This flag can be set when initializing the vsock address > variable used for the connect() call. > > Signed-off-by: Andra Paraschiv > --- > include/uapi/linux/vm_sockets.h | 18 +- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h > index fd0ed7221645d..58da5a91413ac 100644 > --- a/include/uapi/linux/vm_sockets.h > +++ b/include/uapi/linux/vm_sockets.h > @@ -114,6 +114,22 @@ > > #define VMADDR_CID_HOST 2 > > +/* This sockaddr_vm flag value covers the current default use case: > + * local vsock communication between guest and host and nested VMs setup. > + * In addition to this, implicitly, the vsock packets are forwarded to the > host > + * if no host->guest vsock transport is set. > + */ > +#define VMADDR_FLAG_DEFAULT_COMMUNICATION0x > + > +/* Set this flag value in the sockaddr_vm corresponding field if the vsock > + * channel needs to be setup between two sibling VMs running on the same > host. > + * This way can explicitly distinguish between vsock channels created for > nested > + * VMs (or local communication between guest and host) and the ones created > for > + * sibling VMs. And vsock channels for multiple use cases (nested / sibling > VMs) > + * can be setup at the same time. > + */ > +#define VMADDR_FLAG_SIBLING_VMS_COMMUNICATION0x0001 vsock has the h2g and g2h concept. It would be more general to call this flag VMADDR_FLAG_G2H or less cryptically VMADDR_FLAG_TO_HOST. That way it just tells the driver in which direction to send packets without implying that sibling communication is possible (it's not allowed by default on any transport). I don't have a strong opinion on this but wanted to suggest the idea. Stefan signature.asc Description: PGP signature
Re: [PATCH net-next v1 1/3] vm_sockets: Include flag field in the vsock address data structure
On Tue, Dec 01, 2020 at 08:15:04PM +0200, Paraschiv, Andra-Irina wrote: On 01/12/2020 18:09, Stefano Garzarella wrote: On Tue, Dec 01, 2020 at 05:25:03PM +0200, Andra Paraschiv wrote: vsock enables communication between virtual machines and the host they are running on. With the multi transport support (guest->host and host->guest), nested VMs can also use vsock channels for communication. In addition to this, by default, all the vsock packets are forwarded to the host, if no host->guest transport is loaded. This behavior can be implicitly used for enabling vsock communication between sibling VMs. Add a flag field in the vsock address data structure that can be used to explicitly mark the vsock connection as being targeted for a certain type of communication. This way, can distinguish between nested VMs and sibling VMs use cases and can also setup them at the same time. Till now, could either have nested VMs or sibling VMs at a time using the vsock communication stack. Use the already available "svm_reserved1" field and mark it as a flag field instead. This flag can be set when initializing the vsock address variable used for the connect() call. Maybe we can split this patch in 2 patches, one to rename the svm_flag and one to add the new flags. Sure, I can split this in 2 patches, to have a bit more separation of duties. Signed-off-by: Andra Paraschiv --- include/uapi/linux/vm_sockets.h | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h index fd0ed7221645d..58da5a91413ac 100644 --- a/include/uapi/linux/vm_sockets.h +++ b/include/uapi/linux/vm_sockets.h @@ -114,6 +114,22 @@ #define VMADDR_CID_HOST 2 +/* This sockaddr_vm flag value covers the current default use case: + * local vsock communication between guest and host and nested VMs setup. + * In addition to this, implicitly, the vsock packets are forwarded to the host + * if no host->guest vsock transport is set. + */ +#define VMADDR_FLAG_DEFAULT_COMMUNICATION 0x I think we don't need this macro, since the next one can be used to check if it a sibling communication (flag 0x1 set) or not (flag 0x1 not set). Right, that's not particularly the use of the flag value, as by default comes as 0. It was more for sharing the cases this covers. But I can remove the define and keep this kind of info, with regard to the default case, in the commit message / comments. Agree, you can add few lines in the comment block of VMADDR_FLAG_SIBLING describing the default case when it is not set. + +/* Set this flag value in the sockaddr_vm corresponding field if the vsock + * channel needs to be setup between two sibling VMs running on the same host. + * This way can explicitly distinguish between vsock channels created for nested + * VMs (or local communication between guest and host) and the ones created for + * sibling VMs. And vsock channels for multiple use cases (nested / sibling VMs) + * can be setup at the same time. + */ +#define VMADDR_FLAG_SIBLING_VMS_COMMUNICATION 0x0001 What do you think if we shorten in VMADDR_FLAG_SIBLING? Yup, this seems ok as well for me. I'll update the naming. Thanks, Stefano
Re: [PATCH net-next v1 1/3] vm_sockets: Include flag field in the vsock address data structure
On 01/12/2020 18:09, Stefano Garzarella wrote:
On Tue, Dec 01, 2020 at 05:25:03PM +0200, Andra Paraschiv wrote:
vsock enables communication between virtual machines and the host they
are running on. With the multi transport support (guest->host and
host->guest), nested VMs can also use vsock channels for communication.
In addition to this, by default, all the vsock packets are forwarded to
the host, if no host->guest transport is loaded. This behavior can be
implicitly used for enabling vsock communication between sibling VMs.
Add a flag field in the vsock address data structure that can be used to
explicitly mark the vsock connection as being targeted for a certain
type of communication. This way, can distinguish between nested VMs and
sibling VMs use cases and can also setup them at the same time. Till
now, could either have nested VMs or sibling VMs at a time using the
vsock communication stack.
Use the already available "svm_reserved1" field and mark it as a flag
field instead. This flag can be set when initializing the vsock address
variable used for the connect() call.
Maybe we can split this patch in 2 patches, one to rename the svm_flag
and one to add the new flags.
Sure, I can split this in 2 patches, to have a bit more separation of
duties.
Signed-off-by: Andra Paraschiv
---
include/uapi/linux/vm_sockets.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/vm_sockets.h
b/include/uapi/linux/vm_sockets.h
index fd0ed7221645d..58da5a91413ac 100644
--- a/include/uapi/linux/vm_sockets.h
+++ b/include/uapi/linux/vm_sockets.h
@@ -114,6 +114,22 @@
#define VMADDR_CID_HOST 2
+/* This sockaddr_vm flag value covers the current default use case:
+ * local vsock communication between guest and host and nested VMs
setup.
+ * In addition to this, implicitly, the vsock packets are forwarded
to the host
+ * if no host->guest vsock transport is set.
+ */
+#define VMADDR_FLAG_DEFAULT_COMMUNICATION 0x
I think we don't need this macro, since the next one can be used to
check if it a sibling communication (flag 0x1 set) or not (flag 0x1
not set).
Right, that's not particularly the use of the flag value, as by default
comes as 0. It was more for sharing the cases this covers. But I can
remove the define and keep this kind of info, with regard to the default
case, in the commit message / comments.
+
+/* Set this flag value in the sockaddr_vm corresponding field if the
vsock
+ * channel needs to be setup between two sibling VMs running on the
same host.
+ * This way can explicitly distinguish between vsock channels
created for nested
+ * VMs (or local communication between guest and host) and the ones
created for
+ * sibling VMs. And vsock channels for multiple use cases (nested /
sibling VMs)
+ * can be setup at the same time.
+ */
+#define VMADDR_FLAG_SIBLING_VMS_COMMUNICATION 0x0001
What do you think if we shorten in VMADDR_FLAG_SIBLING?
Yup, this seems ok as well for me. I'll update the naming.
Thanks,
Andra
+
/* Invalid vSockets version. */
#define VM_SOCKETS_INVALID_VERSION -1U
@@ -145,7 +161,7 @@
struct sockaddr_vm {
__kernel_sa_family_t svm_family;
- unsigned short svm_reserved1;
+ unsigned short svm_flag;
unsigned int svm_port;
unsigned int svm_cid;
unsigned char svm_zero[sizeof(struct sockaddr) -
--
2.20.1 (Apple Git-117)
Amazon Development Center (Romania) S.R.L. registered office: 27A Sf.
Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania.
Registered in Romania. Registration number J22/2621/2005.
Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar
Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in
Romania. Registration number J22/2621/2005.
Re: [PATCH net-next v1 1/3] vm_sockets: Include flag field in the vsock address data structure
On Tue, Dec 01, 2020 at 05:25:03PM +0200, Andra Paraschiv wrote:
vsock enables communication between virtual machines and the host they
are running on. With the multi transport support (guest->host and
host->guest), nested VMs can also use vsock channels for communication.
In addition to this, by default, all the vsock packets are forwarded to
the host, if no host->guest transport is loaded. This behavior can be
implicitly used for enabling vsock communication between sibling VMs.
Add a flag field in the vsock address data structure that can be used to
explicitly mark the vsock connection as being targeted for a certain
type of communication. This way, can distinguish between nested VMs and
sibling VMs use cases and can also setup them at the same time. Till
now, could either have nested VMs or sibling VMs at a time using the
vsock communication stack.
Use the already available "svm_reserved1" field and mark it as a flag
field instead. This flag can be set when initializing the vsock address
variable used for the connect() call.
Maybe we can split this patch in 2 patches, one to rename the svm_flag
and one to add the new flags.
Signed-off-by: Andra Paraschiv
---
include/uapi/linux/vm_sockets.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h
index fd0ed7221645d..58da5a91413ac 100644
--- a/include/uapi/linux/vm_sockets.h
+++ b/include/uapi/linux/vm_sockets.h
@@ -114,6 +114,22 @@
#define VMADDR_CID_HOST 2
+/* This sockaddr_vm flag value covers the current default use case:
+ * local vsock communication between guest and host and nested VMs setup.
+ * In addition to this, implicitly, the vsock packets are forwarded to the host
+ * if no host->guest vsock transport is set.
+ */
+#define VMADDR_FLAG_DEFAULT_COMMUNICATION 0x
I think we don't need this macro, since the next one can be used to
check if it a sibling communication (flag 0x1 set) or not (flag 0x1
not set).
+
+/* Set this flag value in the sockaddr_vm corresponding field if the vsock
+ * channel needs to be setup between two sibling VMs running on the same host.
+ * This way can explicitly distinguish between vsock channels created for
nested
+ * VMs (or local communication between guest and host) and the ones created for
+ * sibling VMs. And vsock channels for multiple use cases (nested / sibling
VMs)
+ * can be setup at the same time.
+ */
+#define VMADDR_FLAG_SIBLING_VMS_COMMUNICATION 0x0001
What do you think if we shorten in VMADDR_FLAG_SIBLING?
Thanks,
Stefano
+
/* Invalid vSockets version. */
#define VM_SOCKETS_INVALID_VERSION -1U
@@ -145,7 +161,7 @@
struct sockaddr_vm {
__kernel_sa_family_t svm_family;
- unsigned short svm_reserved1;
+ unsigned short svm_flag;
unsigned int svm_port;
unsigned int svm_cid;
unsigned char svm_zero[sizeof(struct sockaddr) -
--
2.20.1 (Apple Git-117)
Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar
Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in
Romania. Registration number J22/2621/2005.
[PATCH net-next v1 1/3] vm_sockets: Include flag field in the vsock address data structure
vsock enables communication between virtual machines and the host they
are running on. With the multi transport support (guest->host and
host->guest), nested VMs can also use vsock channels for communication.
In addition to this, by default, all the vsock packets are forwarded to
the host, if no host->guest transport is loaded. This behavior can be
implicitly used for enabling vsock communication between sibling VMs.
Add a flag field in the vsock address data structure that can be used to
explicitly mark the vsock connection as being targeted for a certain
type of communication. This way, can distinguish between nested VMs and
sibling VMs use cases and can also setup them at the same time. Till
now, could either have nested VMs or sibling VMs at a time using the
vsock communication stack.
Use the already available "svm_reserved1" field and mark it as a flag
field instead. This flag can be set when initializing the vsock address
variable used for the connect() call.
Signed-off-by: Andra Paraschiv
---
include/uapi/linux/vm_sockets.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h
index fd0ed7221645d..58da5a91413ac 100644
--- a/include/uapi/linux/vm_sockets.h
+++ b/include/uapi/linux/vm_sockets.h
@@ -114,6 +114,22 @@
#define VMADDR_CID_HOST 2
+/* This sockaddr_vm flag value covers the current default use case:
+ * local vsock communication between guest and host and nested VMs setup.
+ * In addition to this, implicitly, the vsock packets are forwarded to the host
+ * if no host->guest vsock transport is set.
+ */
+#define VMADDR_FLAG_DEFAULT_COMMUNICATION 0x
+
+/* Set this flag value in the sockaddr_vm corresponding field if the vsock
+ * channel needs to be setup between two sibling VMs running on the same host.
+ * This way can explicitly distinguish between vsock channels created for
nested
+ * VMs (or local communication between guest and host) and the ones created for
+ * sibling VMs. And vsock channels for multiple use cases (nested / sibling
VMs)
+ * can be setup at the same time.
+ */
+#define VMADDR_FLAG_SIBLING_VMS_COMMUNICATION 0x0001
+
/* Invalid vSockets version. */
#define VM_SOCKETS_INVALID_VERSION -1U
@@ -145,7 +161,7 @@
struct sockaddr_vm {
__kernel_sa_family_t svm_family;
- unsigned short svm_reserved1;
+ unsigned short svm_flag;
unsigned int svm_port;
unsigned int svm_cid;
unsigned char svm_zero[sizeof(struct sockaddr) -
--
2.20.1 (Apple Git-117)
Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar
Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in
Romania. Registration number J22/2621/2005.
