+ if (protocol)
+ return -EPROTONOSUPPORT;
+
IMO protocol == PF_VSOCK should not get rejected here.
Good catch, I've sent out a patch for this.
Thanks!
- Andy
___
Virtualization mailing list
Hi Gerd,
+ written = transport-stream_enqueue(
+ vsk, msg-msg_iov,
+ len - total_written);
Hmm, shouldn't we pass total_written to stream_enqueue here?
In case a blocking send(big-buffer) call gets splitted into multiple
Hi Sasha,
+ * Specifically, we initialize the vsock_bind_table array to a size of
+ * VSOCK_HASH_SIZE + 1 so that vsock_bind_table[0] through
...
Why isn't it using the kernel's linux/hashtable.h?
Gah, that's a leftover from when it was platform independent :/ I have a
patch lying around
On 02/07/13 01:23, Andy King wrote:
+/* Use this as the destination CID in an address when referring to the
+ * hypervisor. VMCI relies on it being 0, but this would be useful for other
+ * transports too.
+ */
+
+#define VMADDR_CID_HYPERVISOR 0
+
+/* This CID is specific to VMCI and can
Hi,
I've seen you have a notify_ops in the vmci bits. Do you have different
notify ops depending on socket type or something? Does it make sense to
move the notify ops ptr into struct vsock_sock maybe?
The notify stuff only applies to STREAMs. However, we have two different
notify
Hi Andy,
On Wed, Feb 6, 2013 at 7:23 PM, Andy King ack...@vmware.com wrote:
+ * Specifically, we initialize the vsock_bind_table array to a size of
+ * VSOCK_HASH_SIZE + 1 so that vsock_bind_table[0] through
+ * vsock_bind_table[VSOCK_HASH_SIZE - 1] are for bound sockets and
+ *
On 02/12/13 16:21, Andy King wrote:
Hi Gerd,
+struct vsock_transport {
...
Whoa. This has grown *alot*. Care to explain this please? Patch
creating a Documentation/virtual/vsock.txt would be cool.
Yes, it grew because of the notification stuff, which I'd forgotten
about until I
On 02/07/13 01:23, Andy King wrote:
+static int vsock_create(struct net *net, struct socket *sock,
+ int protocol, int kern)
+{
+ if (!sock)
+ return -EINVAL;
+
+ if (protocol)
+ return -EPROTONOSUPPORT;
+
IMO protocol == PF_VSOCK
+ if (protocol)
+ return -EPROTONOSUPPORT;
+
IMO protocol == PF_VSOCK should not get rejected here.
Agreed, let me fix that too.
Thanks!
- Andy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
I've seen you have a notify_ops in the vmci bits. Do you have different
notify ops depending on socket type or something? Does it make sense to
move the notify ops ptr into struct vsock_sock maybe?
The notify stuff only applies to STREAMs. However, we have two different
notify impls, one
On 02/07/13 01:23, Andy King wrote:
Hi,
+/* Option name for socket's service label. Use as the option name in
+ * setsockopt(3) or getsockopt(3) to set or get the service label for a
socket.
+ * The service label is a C-style NUL-terminated string. Only available for
+ * hypervisor
Hi Gerd,
+struct vsock_transport {
...
Whoa. This has grown *alot*. Care to explain this please? Patch
creating a Documentation/virtual/vsock.txt would be cool.
Yes, it grew because of the notification stuff, which I'd forgotten
about until I removed the vmci header from the core code.
stream_has_data: Returns amount of data available (in bytes) in the
socket's receive buffer, or -1 if empty.
stream_has_space: Returns amount of space available (in bytes) in the
socket's send buffer, or -1 if full.
Actually, I think it's for empty/full, and -1 for an error (say, the
Hi Gerd,
+/* Option name for socket's service label. Use as the option name in
+ * setsockopt(3) or getsockopt(3) to set or get the service label for a
socket.
+ * The service label is a C-style NUL-terminated string. Only available
for
+ * hypervisor endpoints.
+ */
+
On 02/07/13 01:23, Andy King wrote:
+struct vsock_transport_recv_notify_data {
+ u64 data1; /* Transport-defined. */
+ u64 data2; /* Transport-defined. */
+ bool notify_on_block;
+};
+
+struct vsock_transport_send_notify_data {
+ u64 data1; /* Transport-defined. */
+
Hi Gerd,
From my side the minimum requirement is to have
vsock_(un)register_transport calls available, so it is possible to
write a virtio transport module without having to patch vsock code
to hook it up.
We've done exactly that. It's now split into two separate modules,
with the core
Hi,
Likewise, I expect with the final version vmci_transport is a
separate module (or moves into the vmci driver), correct?
When you say final, do you mean something that we have to do before
acceptance into mainline or something we can refine over time?
IMHO refining in-tree is fine.
Hi Gerd,
Thanks so much for taking a look and apologies for the delay!
+config VMWARE_VSOCK
+ tristate Virtual Socket protocol
+ depends on VMWARE_VMCI
I guess this is temporary? Cover letter says *mostly* separated ...
Yes, right now everything is still munged into one driver.
On Fri, Jan 25, 2013 at 04:15:19PM -0800, Dmitry Torokhov wrote:
Hi Neil,
On Friday, January 25, 2013 06:59:53 PM Neil Horman wrote:
On Fri, Jan 25, 2013 at 09:37:50AM -0800, ack...@vmware.com wrote:
+
+config VMWARE_VSOCK
+ tristate Virtual Socket protocol
+ depends on
Hi Neil,
On Friday, January 25, 2013 06:59:53 PM Neil Horman wrote:
On Fri, Jan 25, 2013 at 09:37:50AM -0800, ack...@vmware.com wrote:
+
+config VMWARE_VSOCK
+ tristate Virtual Socket protocol
+ depends on VMWARE_VMCI
What is CONFIG_VMWARE_VMCI? I don't find that in any Kconfig
On Fri, Jan 25, 2013 at 04:15:19PM -0800, Dmitry Torokhov wrote:
Hi Neil,
On Friday, January 25, 2013 06:59:53 PM Neil Horman wrote:
On Fri, Jan 25, 2013 at 09:37:50AM -0800, ack...@vmware.com wrote:
+
+config VMWARE_VSOCK
+ tristate Virtual Socket protocol
+ depends on
On Fri, Jan 25, 2013 at 09:37:50AM -0800, ack...@vmware.com wrote:
From: Andy King ack...@vmware.com
VM Sockets allows communication between virtual machines and the hypervisor.
User level applications both in a virtual machine and on the host can use the
VM Sockets API, which facilitates
22 matches
Mail list logo
