[PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets

[Dexuan Cui]

> From: devel [mailto:driverdev-devel-bounces at linuxdriverproject.org] On
> Behalf Of Dexuan Cui
> ...
> > From: David Miller [mailto:davem at davemloft.net]
> > ...
> > From: Dexuan Cui <decui at 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