* [PATCH v16 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
@ 2016-07-11 14:54 Dexuan Cui
2016-07-13 7:30 ` Michal Kubecek
0 siblings, 1 reply; 3+ messages in thread
From: Dexuan Cui @ 2016-07-11 14:54 UTC (permalink / raw)
To: davem, gregkh, netdev, linux-kernel, devel, olaf, apw, jasowang,
Vitaly Kuznetsov, Cathy Avery, KY Srinivasan, joe,
Rolf Neugebauer
Cc: Haiyang Zhang, Dave Scott
[-- Attachment #1: Type: text/plain, Size: 8878 bytes --]
FYI: you can also get the patch by (commit 5dde7975):
https://github.com/dcui/linux/tree/decui/hv_sock/net-next/20160711_v16
The delta changes between v15 and v16 are in the attached patch
delta_v15_vs_v16.patch.
------------------------------------------
Hyper-V Sockets (hv_sock) supplies a byte-stream based communication
mechanism between the host and the guest. It's somewhat like TCP over
VMBus, but the transportation layer (VMBus) is much simpler than IP.
With Hyper-V Sockets, applications between the host and the guest can talk
to each other directly by the traditional BSD-style socket APIs.
Hyper-V Sockets is only available on new Windows hosts, like Windows Server
2016. More info is in this article "Make your own integration services":
https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/develop/make_mgmt_service
The patch implements the necessary support in the guest side by
introducing a new socket address family AF_HYPERV.
Note: the VMBus driver side's supporting patches have been in the mainline
tree.
I know the kernel has already had a VM Sockets driver (AF_VSOCK) based
on VMware VMCI (net/vmw_vsock/, drivers/misc/vmw_vmci), and KVM is
proposing AF_VSOCK of virtio version:
http://marc.info/?l=linux-netdev&m=145952064004765&w=2
However, though Hyper-V Sockets may seem conceptually similar to
AF_VOSCK, there are differences in the transportation layer, and IMO these
make the direct code reusing impractical:
1. In AF_VSOCK, the endpoint type is: <u32 ContextID, u32 Port>, but in
AF_HYPERV, the endpoint type is: <GUID VM_ID, GUID ServiceID>. Here GUID
is 128-bit.
2. AF_VSOCK supports SOCK_DGRAM, while AF_HYPERV doesn't.
3. AF_VSOCK supports some special sock opts, like SO_VM_SOCKETS_BUFFER_SIZE,
SO_VM_SOCKETS_BUFFER_MIN/MAX_SIZE and SO_VM_SOCKETS_CONNECT_TIMEOUT.
These are meaningless to AF_HYPERV.
4. Some AF_VSOCK's VMCI transportation ops are meanless to AF_HYPERV/VMBus,
like .notify_recv_init
.notify_recv_pre_block
.notify_recv_pre_dequeue
.notify_recv_post_dequeue
.notify_send_init
.notify_send_pre_block
.notify_send_pre_enqueue
.notify_send_post_enqueue
etc.
So I think we'd better introduce a new address family: AF_HYPERV.
Please review the patch.
Looking forward to your comments, especially comments from David. :-)
Changes since v1:
- updated "[PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature"
- added __init and __exit for the module init/exit functions
- net/hv_sock/Kconfig: "default m" -> "default m if HYPERV"
- MODULE_LICENSE: "Dual MIT/GPL" -> "Dual BSD/GPL"
Changes since v2:
- fixed various coding issue pointed out by David Miller
- fixed indentation issues
- removed pr_debug in net/hv_sock/af_hvsock.c
- used reverse-Chrismas-tree style for local variables.
- EXPORT_SYMBOL -> EXPORT_SYMBOL_GPL
Changes since v3:
- fixed a few coding issue pointed by Vitaly Kuznetsov and Dan Carpenter
- fixed the ret value in vmbus_recvpacket_hvsock on error
- fixed the style of multi-line comment: vmbus_get_hvsock_rw_status()
Changes since v4 (https://lkml.org/lkml/2015/7/28/404):
- addressed all the comments about V4.
- treat the hvsock offers/channels as special VMBus devices
- add a mechanism to pass hvsock events to the hvsock driver
- fixed some corner cases with proper locking when a connection is closed
- rebased to the latest Greg's tree
Changes since v5 (https://lkml.org/lkml/2015/12/24/103):
- addressed the coding style issues (Vitaly Kuznetsov & David Miller, thanks!)
- used a better coding for the per-channel rescind callback (Thank Vitaly!)
- avoided the introduction of new VMBUS driver APIs vmbus_sendpacket_hvsock()
and vmbus_recvpacket_hvsock() and used vmbus_sendpacket()/vmbus_recvpacket()
in the higher level (i.e., the vmsock driver). Thank Vitaly!
Changes since v6 (http://lkml.iu.edu/hypermail/linux/kernel/1601.3/01813.html)
- only a few minor changes of coding style and comments
Changes since v7
- a few minor changes of coding style: thanks, Joe Perches!
- added some lines of comments about GUID/UUID before the struct sockaddr_hv.
Changes since v8
- removed the unnecessary __packed for some definitions: thanks, David!
- hvsock_open_connection: use offer.u.pipe.user_def[0] to know the connection
and reorganized the function
direction
- reorganized the code according to suggestions from Cathy Avery: split big
functions into small ones, set .setsockopt and getsockopt to
sock_no_setsockopt/sock_no_getsockopt
- inline'd some small list helper functions
Changes since v9
- minimized struct hvsock_sock by making the send/recv buffers pointers.
the buffers are allocated by kmalloc() in __hvsock_create() now.
- minimized the sizes of the send/recv buffers and the vmbus ringbuffers.
Changes since v10
1) add module params: send_ring_page, recv_ring_page. They can be used to
enlarge the ringbuffer size to get better performance, e.g.,
# modprobe hv_sock recv_ring_page=16 send_ring_page=16
By default, recv_ring_page is 3 and send_ring_page is 2.
2) add module param max_socket_number (the default is 1024).
A user can enlarge the number to create more than 1024 hv_sock sockets.
By default, 1024 sockets take about 1024 * (3+2+1+1) * 4KB = 28M bytes.
(Here 1+1 means 1 page for send/recv buffers per connection, respectively.)
3) implement the TODO in hvsock_shutdown().
4) fix a bug in hvsock_close_connection():
I remove "sk->sk_socket->state = SS_UNCONNECTED;" -- actually this line
is not really useful. For a connection triggered by a host app's connect(),
sk->sk_socket remains NULL before the connection is accepted by the server
app (in Linux VM): see hvsock_accept() -> hvsock_accept_wait() ->
sock_graft(connected, newsock). If the host app exits before the server
app's accept() returns, the host can send a rescind-message to close the
connection and later in the Linux VM's message handler
i.e. vmbus_onoffer_rescind()), Linux will get a NULL de-referencing crash.
5) fix a bug in hvsock_open_connection()
I move the vmbus_set_chn_rescind_callback() to a later place, because
when vmbus_open() fails, hvsock_close_connection() can do nothing and we
count on vmbus_onoffer_rescind() -> vmbus_device_unregister() to clean up
the device.
6) some stylistic modificiation.
Changes since v11:
1) remove the module params as David suggested.
2) use 5 exact pages for VMBus send/recv rings, respectively.
The host side's design of the feature requires 5 exact pages for recv/send
rings respectively -- this is suboptimal considering memory consumption,
however unluckily we have to live with it, before the host comes up with
a new design in the future. :-(
3) remove the per-connection static send/recv buffers
Instead, we allocate and free the buffers dynamically only when we recv/send
data. This means: when a connection is idle, no memory is consumed as
recv/send buffers at all.
Dexuan Cui (1):
hv_sock: introduce Hyper-V Sockets
Changes since v12:
return ENOMEM on buffer alllocation failure
Actually "man read/write" says "Other errors may occur, depending on the
object connected to fd". "man send/recv" indeed lists ENOMEM.
Considering AF_HYPERV is a new socket type, ENOMEM seems OK here.
In the long run, I think we should add a new API in the VMBus driver,
allowing data copy from VMBus ringbuffer into user mode buffer directly.
This way, we can even eliminate this temporary buffer.
Changes since v13:
fix some coding style issues pointed out by David.
Changes since v14:
Just some stylistic changes addressing comments from Joe Perches and
Olaf Hering -- thank you!
- add a GPL blurb.
- define a new macro PAGE_SIZE_4K and use it to replace PAGE_SIZE
- change sk_to_hvsock/hvsock_to_sk() from macros to inline functions
- remove a not-very-useful pr_err()
- fix some typos in comment and coding style issues.
Changes since v15:
Made stylistic changes addressing comments from Vitaly Kuznetsov.
Thank you very much for the detailed comments, Vitaly!
Dexuan Cui (1):
hv_sock: introduce Hyper-V Sockets
MAINTAINERS | 2 +
include/linux/hyperv.h | 13 +
include/linux/socket.h | 4 +-
include/net/af_hvsock.h | 78 +++
include/uapi/linux/hyperv.h | 23 +
net/Kconfig | 1 +
net/Makefile | 1 +
net/hv_sock/Kconfig | 10 +
net/hv_sock/Makefile | 3 +
net/hv_sock/af_hvsock.c | 1509 +++++++++++++++++++++++++++++++++++++++++++
10 files changed, 1643 insertions(+), 1 deletion(-)
create mode 100644 include/net/af_hvsock.h
create mode 100644 net/hv_sock/Kconfig
create mode 100644 net/hv_sock/Makefile
create mode 100644 net/hv_sock/af_hvsock.c
--
2.1.0
[-- Attachment #2: delta_v15_vs_v16.patch --]
[-- Type: application/octet-stream, Size: 7849 bytes --]
diff --git a/include/uapi/linux/hyperv.h b/include/uapi/linux/hyperv.h
index d942996..eb3e44b 100644
--- a/include/uapi/linux/hyperv.h
+++ b/include/uapi/linux/hyperv.h
@@ -405,12 +405,11 @@ struct hv_kvp_ip_msg {
* the first 3 fields. Refer to:
* https://en.wikipedia.org/wiki/Globally_unique_identifier
*/
-#define guid_t uuid_le
struct sockaddr_hv {
__kernel_sa_family_t shv_family; /* Address family */
u16 reserved; /* Must be Zero */
- guid_t shv_vm_id; /* VM ID */
- guid_t shv_service_id; /* Service ID */
+ uuid_le shv_vm_guid; /* VM ID */
+ uuid_le shv_service_guid; /* Service ID */
};
#define SHV_VMID_GUEST NULL_UUID_LE
diff --git a/net/hv_sock/Kconfig b/net/hv_sock/Kconfig
index 1f41848..ff84875 100644
--- a/net/hv_sock/Kconfig
+++ b/net/hv_sock/Kconfig
@@ -3,8 +3,8 @@ config HYPERV_SOCK
depends on HYPERV
default m if HYPERV
help
- Hyper-V Sockets is somewhat like TCP over VMBus, allowing
- communication between Linux guest and Hyper-V host without TCP/IP.
+ Hyper-V Sockets is a socket interface for high speed
+ communication between Linux guest and Hyper-V host over VMBus.
To compile this driver as a module, choose M here: the module
will be called hv_sock.
diff --git a/net/hv_sock/af_hvsock.c b/net/hv_sock/af_hvsock.c
index f339f38..d86b879 100644
--- a/net/hv_sock/af_hvsock.c
+++ b/net/hv_sock/af_hvsock.c
@@ -50,22 +50,22 @@ static struct proto hvsock_proto = {
#define SS_LISTEN 255
+#define HVSOCK_CONNECT_TIMEOUT (30 * HZ)
+
+/* This is an artificial limit */
+#define HVSOCK_MAX_BACKLOG 128
+
static LIST_HEAD(hvsock_bound_list);
static LIST_HEAD(hvsock_connected_list);
static DEFINE_MUTEX(hvsock_mutex);
-static bool uuid_equals(uuid_le u1, uuid_le u2)
-{
- return !uuid_le_cmp(u1, u2);
-}
-
static struct sock *hvsock_find_bound_socket(const struct sockaddr_hv *addr)
{
struct hvsock_sock *hvsk;
list_for_each_entry(hvsk, &hvsock_bound_list, bound_list) {
- if (uuid_equals(addr->shv_service_id,
- hvsk->local_addr.shv_service_id))
+ if (!uuid_le_cmp(addr->shv_service_guid,
+ hvsk->local_addr.shv_service_guid))
return hvsock_to_sk(hvsk);
}
return NULL;
@@ -147,7 +147,7 @@ static void hvsock_addr_init(struct sockaddr_hv *addr, uuid_le service_id)
{
memset(addr, 0, sizeof(*addr));
addr->shv_family = AF_HYPERV;
- addr->shv_service_id = service_id;
+ addr->shv_service_guid = service_id;
}
static int hvsock_addr_validate(const struct sockaddr_hv *addr)
@@ -166,7 +166,7 @@ static int hvsock_addr_validate(const struct sockaddr_hv *addr)
static bool hvsock_addr_bound(const struct sockaddr_hv *addr)
{
- return !uuid_equals(addr->shv_service_id, SHV_SERVICE_ID_ANY);
+ return !!uuid_le_cmp(addr->shv_service_guid, SHV_SERVICE_ID_ANY);
}
static int hvsock_addr_cast(const struct sockaddr *addr, size_t len,
@@ -185,13 +185,13 @@ static int __hvsock_do_bind(struct hvsock_sock *hvsk,
struct sockaddr_hv hv_addr;
int ret = 0;
- hvsock_addr_init(&hv_addr, addr->shv_service_id);
+ hvsock_addr_init(&hv_addr, addr->shv_service_guid);
mutex_lock(&hvsock_mutex);
- if (uuid_equals(addr->shv_service_id, SHV_SERVICE_ID_ANY)) {
+ if (!uuid_le_cmp(addr->shv_service_guid, SHV_SERVICE_ID_ANY)) {
do {
- uuid_le_gen(&hv_addr.shv_service_id);
+ uuid_le_gen(&hv_addr.shv_service_guid);
} while (hvsock_find_bound_socket(&hv_addr));
} else {
if (hvsock_find_bound_socket(&hv_addr)) {
@@ -200,7 +200,7 @@ static int __hvsock_do_bind(struct hvsock_sock *hvsk,
}
}
- hvsock_addr_init(&hvsk->local_addr, hv_addr.shv_service_id);
+ hvsock_addr_init(&hvsk->local_addr, hv_addr.shv_service_guid);
sock_hold(&hvsk->sk);
list_add(&hvsk->bound_list, &hvsock_bound_list);
@@ -366,7 +366,7 @@ static int hvsock_bind(struct socket *sock, struct sockaddr *addr,
if (hvsock_addr_cast(addr, addr_len, &hv_addr) != 0)
return -EINVAL;
- if (!uuid_equals(hv_addr->shv_vm_id, NULL_UUID_LE))
+ if (uuid_le_cmp(hv_addr->shv_vm_guid, NULL_UUID_LE))
return -EINVAL;
lock_sock(sk);
@@ -609,7 +609,6 @@ static unsigned int hvsock_poll(struct file *file, struct socket *sock,
if (!(sk->sk_shutdown & RCV_SHUTDOWN) && can_read)
mask |= POLLIN | POLLRDNORM;
} else {
- can_read = false;
can_write = false;
}
@@ -654,10 +653,7 @@ static void hvsock_on_channel_cb(void *ctx)
hvsk = sk_to_hvsock(sk);
channel = hvsk->channel;
- if (!channel) {
- WARN_ONCE(1, "NULL channel! There is a programming bug.\n");
- return;
- }
+ BUG_ON(!channel);
get_ringbuffer_rw_status(channel, &can_read, &can_write);
@@ -720,7 +716,7 @@ static int hvsock_open_connection(struct vmbus_channel *channel)
if (conn_from_host) {
if (sk->sk_ack_backlog >= sk->sk_max_ack_backlog) {
- ret = -EMFILE;
+ ret = -ECONNREFUSED;
goto out;
}
@@ -811,7 +807,7 @@ static int hvsock_connect_wait(struct socket *sock,
long timeout;
hvsk = sk_to_hvsock(sk);
- timeout = 30 * HZ;
+ timeout = HVSOCK_CONNECT_TIMEOUT;
prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
while (sk->sk_state != SS_CONNECTED && sk->sk_err == 0) {
@@ -905,8 +901,8 @@ static int hvsock_connect(struct socket *sock, struct sockaddr *addr,
sk->sk_state = SS_CONNECTING;
ret = vmbus_send_tl_connect_request(
- &hvsk->local_addr.shv_service_id,
- &hvsk->remote_addr.shv_service_id);
+ &hvsk->local_addr.shv_service_guid,
+ &hvsk->remote_addr.shv_service_guid);
if (ret < 0)
goto out;
@@ -964,15 +960,12 @@ static int hvsock_accept_wait(struct sock *listener,
lock_sock(connected);
hvconnected = sk_to_hvsock(connected);
- if (ret) {
- release_sock(connected);
- sock_put(connected);
- } else {
+ if (!ret) {
newsock->state = SS_CONNECTED;
sock_graft(connected, newsock);
- release_sock(connected);
- sock_put(connected);
}
+ release_sock(connected);
+ sock_put(connected);
}
out_wait:
@@ -1029,9 +1022,8 @@ static int hvsock_listen(struct socket *sock, int backlog)
ret = -EINVAL;
goto out;
}
- /* This is an artificial limit */
- if (backlog > 128)
- backlog = 128;
+ if (backlog > HVSOCK_MAX_BACKLOG)
+ backlog = HVSOCK_MAX_BACKLOG;
hvsk = sk_to_hvsock(sk);
if (!hvsock_addr_bound(&hvsk->local_addr)) {
@@ -1057,7 +1049,7 @@ static int hvsock_sendmsg_wait(struct sock *sk, struct msghdr *msg,
DEFINE_WAIT(wait);
bool can_write;
long timeout;
- int ret = 0;
+ int ret;
timeout = sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT);
prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
@@ -1162,11 +1154,8 @@ static int hvsock_sendmsg(struct socket *sock, struct msghdr *msg,
if (len == 0)
return -EINVAL;
- if (msg->msg_flags & ~MSG_DONTWAIT) {
- pr_err("%s: unsupported flags=0x%x\n", __func__,
- msg->msg_flags);
+ if (msg->msg_flags & ~MSG_DONTWAIT)
return -EOPNOTSUPP;
- }
sk = sock->sk;
hvsk = sk_to_hvsock(sk);
@@ -1201,11 +1190,10 @@ static int hvsock_sendmsg(struct socket *sock, struct msghdr *msg,
out:
release_sock(sk);
- /* ret is a bigger-than-0 total_written or a negative err code. */
- if (ret == 0) {
- WARN(1, "unexpected return value of 0\n");
- ret = -EIO;
- }
+ /* ret should be a bigger-than-0 total_written or a negative err
+ * code.
+ */
+ BUG_ON(ret == 0);
return ret;
}
@@ -1358,7 +1346,6 @@ static int hvsock_recvmsg(struct socket *sock, struct msghdr *msg,
/* We ignore msg->addr_name/len. */
if (flags & ~MSG_DONTWAIT) {
- pr_err("%s: unsupported flags=0x%x\n", __func__, flags);
ret = -EOPNOTSUPP;
goto out;
}
@@ -1478,8 +1465,7 @@ static int __init hvsock_init(void)
{
int ret;
- /* Hyper-V Sockets requires at least VMBus 4.0 */
- if ((vmbus_proto_version >> 16) < 4)
+ if (vmbus_proto_version < VERSION_WIN10)
return -ENODEV;
ret = vmbus_driver_register(&hvsock_drv);
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH v16 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
2016-07-11 14:54 [PATCH v16 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock) Dexuan Cui
@ 2016-07-13 7:30 ` Michal Kubecek
2016-07-13 11:38 ` Dexuan Cui
0 siblings, 1 reply; 3+ messages in thread
From: Michal Kubecek @ 2016-07-13 7:30 UTC (permalink / raw)
To: Dexuan Cui
Cc: davem, gregkh, netdev, linux-kernel, devel, olaf, apw, jasowang,
Vitaly Kuznetsov, Cathy Avery, KY Srinivasan, joe,
Rolf Neugebauer, Haiyang Zhang, Dave Scott
On Mon, Jul 11, 2016 at 02:54:59PM +0000, Dexuan Cui wrote:
>
> I know the kernel has already had a VM Sockets driver (AF_VSOCK) based
> on VMware VMCI (net/vmw_vsock/, drivers/misc/vmw_vmci), and KVM is
> proposing AF_VSOCK of virtio version:
> http://marc.info/?l=linux-netdev&m=145952064004765&w=2
>
> However, though Hyper-V Sockets may seem conceptually similar to
> AF_VOSCK, there are differences in the transportation layer, and IMO these
> make the direct code reusing impractical:
>
> 1. In AF_VSOCK, the endpoint type is: <u32 ContextID, u32 Port>, but in
> AF_HYPERV, the endpoint type is: <GUID VM_ID, GUID ServiceID>. Here GUID
> is 128-bit.
OK, this could be a problem.
> 2. AF_VSOCK supports SOCK_DGRAM, while AF_HYPERV doesn't.
>
> 3. AF_VSOCK supports some special sock opts, like SO_VM_SOCKETS_BUFFER_SIZE,
> SO_VM_SOCKETS_BUFFER_MIN/MAX_SIZE and SO_VM_SOCKETS_CONNECT_TIMEOUT.
> These are meaningless to AF_HYPERV.
>
> 4. Some AF_VSOCK's VMCI transportation ops are meanless to AF_HYPERV/VMBus,
> like .notify_recv_init
> .notify_recv_pre_block
> .notify_recv_pre_dequeue
> .notify_recv_post_dequeue
> .notify_send_init
> .notify_send_pre_block
> .notify_send_pre_enqueue
> .notify_send_post_enqueue
> etc.
>
> So I think we'd better introduce a new address family: AF_HYPERV.
I don't quite understand the logic here. All these sound like "AF_VSOCK
has this feature we don't need so (rather than not using the feature) we
are not going to use AF_VSOCK". I would understand if you pointed out
features important for you that are missing in AF_VSOCK but this kind of
reasoning sounds strange to me.
Michal Kubecek
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [PATCH v16 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
2016-07-13 7:30 ` Michal Kubecek
@ 2016-07-13 11:38 ` Dexuan Cui
0 siblings, 0 replies; 3+ messages in thread
From: Dexuan Cui @ 2016-07-13 11:38 UTC (permalink / raw)
To: Michal Kubecek
Cc: davem, gregkh, netdev, linux-kernel, devel, olaf, apw, jasowang,
Vitaly Kuznetsov, Cathy Avery, KY Srinivasan, joe,
Rolf Neugebauer, Haiyang Zhang, Dave Scott
> From: Michal Kubecek [mailto:mkubecek@suse.cz]
> > ......
> > However, though Hyper-V Sockets may seem conceptually similar to
> > AF_VOSCK, there are differences in the transportation layer, and IMO these
> > make the direct code reusing impractical:
> >
> > 1. In AF_VSOCK, the endpoint type is: <u32 ContextID, u32 Port>, but in
> > AF_HYPERV, the endpoint type is: <GUID VM_ID, GUID ServiceID>. Here GUID
> > is 128-bit.
>
> OK, this could be a problem.
>
> > 2. AF_VSOCK supports SOCK_DGRAM, while AF_HYPERV doesn't.
> >
> > 3. AF_VSOCK supports some special sock opts, like
> SO_VM_SOCKETS_BUFFER_SIZE,
> > SO_VM_SOCKETS_BUFFER_MIN/MAX_SIZE and
> SO_VM_SOCKETS_CONNECT_TIMEOUT.
> > These are meaningless to AF_HYPERV.
> >
> > 4. Some AF_VSOCK's VMCI transportation ops are meanless to
> AF_HYPERV/VMBus,
> > like .notify_recv_init
> > .notify_recv_pre_block
> > .notify_recv_pre_dequeue
> > .notify_recv_post_dequeue
> > .notify_send_init
> > .notify_send_pre_block
> > .notify_send_pre_enqueue
> > .notify_send_post_enqueue
> > etc.
> >
> > So I think we'd better introduce a new address family: AF_HYPERV.
>
> I don't quite understand the logic here. All these sound like "AF_VSOCK
> has this feature we don't need so (rather than not using the feature) we
> are not going to use AF_VSOCK". I would understand if you pointed out
> features important for you that are missing in AF_VSOCK but this kind of
> reasoning sounds strange to me.
>
> Michal Kubecek
Hi Michal,
Sorry, I might not have made me clear.
I didn't mean "AF_VSOCK has this feature we don't need". I didn't mean
"features important for me that are missing in AF_VSOCK", either.
I just wanted to say that I need a new protocol number and I should
have a separate directory in net/, i.e., net/hv_sock/.
Because AF_VSOCK and AF_HYPERV are conceptually similar, some
people asked why I didn't fit my code into net/vmw_vsock/ and I wrote the
text to explain why that wasn't a good idea: the implementation details
are different and I can't directly reuse the vsock code.
Thanks,
-- Dexuan
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-07-13 11:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-11 14:54 [PATCH v16 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock) Dexuan Cui
2016-07-13 7:30 ` Michal Kubecek
2016-07-13 11:38 ` Dexuan Cui
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.