On Fri, Jan 25, 2013 at 09:37:50AM -0800, ack...@vmware.com wrote:
> From: Andy King
>
> 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 fast and effici
Hi,
> diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
> new file mode 100644
> index 000..95e2568
> --- /dev/null
> +++ b/net/vmw_vsock/Kconfig
> @@ -0,0 +1,14 @@
> +#
> +# Vsock protocol
> +#
> +
> +config VMWARE_VSOCK
> + tristate "Virtual Socket protocol"
> + depends on
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 d
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 fi
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 m
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. */
>
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.
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/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 u
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_VSO
> > + 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
https:
> 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, on
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
>
On 02/07/13 01:23, Andy King wrote:
> + 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 g
Hi Andy,
On Wed, Feb 6, 2013 at 7:23 PM, Andy King 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
> + * vsock_bind_table[VSOCK_HASH
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 a
> > + 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
Virtualization@lists.linux-founda
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
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 arou
On 02/18/13 18:07, Andy King wrote:
> 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
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 a
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"
> > > + de
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"
> > > + de
> 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
tr
25 matches
Mail list logo
