Messages in this thread | | | From | Dexuan Cui <> | Subject | RE: [PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets | Date | Tue, 26 Jul 2016 07:09:41 +0000 |
| |
> From: devel [mailto:driverdev-devel-bounces@linuxdriverproject.org] On > Behalf Of Dexuan Cui > ... > > From: David Miller [mailto:davem@davemloft.net] > > ... > > From: Dexuan Cui <decui@microsoft.com> > > Date: Tue, 26 Jul 2016 03:09:16 +0000 > > > > > BTW, during the past month, at least 7 other people also reviewed > > > the patch and gave me quite a few good comments, which have > > > been addressed. > > > > Correction: Several people gave coding style and simple corrections > > to your patch. > > > > Very few gave any review of the _SUBSTANCE_ of your changes. > > > > And the one of the few who did, and suggested you build your > > facilities using the existing S390 hypervisor socket infrastructure, > > you brushed off _IMMEDIATELY_. > > > > That drives me crazy. The one person who gave you real feedback > > you basically didn't consider seriously at all. > > Hi David, > I'm very sorry -- I guess I must have missed something here -- I don't > remember somebody replied with S390 hypervisor socket > infrastructure... I'm re-reading all the replies, trying to locate the > reply and I'll find out why I didn't take it seriously. Sorry in advance.
Hi, David, I checked all the comments I received and all my replies (at least I really tried my best to check my Inbox) , but couldn't find the "S390 hypervisor socket infrastructure" mail.
I googled "S390 hypervisor socket" but didn't find anything related (I think).
I'm really sorry -- could you please give a little more info about it?
If you meant https://lkml.org/lkml/2016/7/13/382, I don't think Michal Kubecek was suggesting I build my code using the existing AF_VSOCK code(?) I think he was only asking me to clarify the way I used to write the text to explain why I can't fit my code into the existing AF_VSOCK code. BTW, AF_VSOCK is not on S390, I think.
If this is the case, I'm sorry I didn't explain the reason clearer. My replies last year explained the reason with more info: https://lkml.org/lkml/2015/7/7/1162 https://lkml.org/lkml/2015/7/17/67 And I thought people agreed that a new address family is justified.
Please let me excerpt the most related snippets in my old replies:
-------------------------------------- The biggest difference is the size of the endpoint (u128 vs. u32): <u32 ContextID, u32 Port> in AF_VOSCK vs. <u128 GUID_VM_ID, u128 GUID_ServiceID> in AF_HYPERV.
In the AF_VSOCK code and the related transport layer (the wrapper ops of VMware's VMCI), the size is widely used in kernel space (and user space application). If I have to fit my code to AF_VSOCK code, I would have to mess up the AF_VSOCK code in many places by adding ugly code like:
IF the endpoint size is <u32, u32> THEN use the existing logic; ELSE use the new logic;
And the user space application has to explicitly handle the different endpoint sizes too. --------------------------------------
Looking forward to your reply!
Thanks, -- Dexuan
| |