-----Original Message-----
From: KY Srinivasan
Sent: Friday, August 7, 2015 2:28
To: Dexuan Cui <decui@microsoft.com>; David Miller <davem@davemloft.net>
Cc: olaf@aepfle.de; gregkh@linuxfoundation.org; jasowang@redhat.com;
driverdev-devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
stephen@networkplumber.org; stefanha@redhat.com; netdev@vger.kernel.org;
apw@canonical.com; pebolle@tiscali.nl; dan.carpenter@oracle.com
Subject: RE: [PATCH V4 4/7] Drivers: hv: vmbus: add APIs to register callbacks to
process hvsock connection

quoted

-----Original Message-----
From: Dexuan Cui
Sent: Wednesday, August 5, 2015 9:54 PM
To: David Miller <davem@davemloft.net>; KY Srinivasan
[off-list ref]
Cc: olaf@aepfle.de; gregkh@linuxfoundation.org; jasowang@redhat.com;
driverdev-devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
stephen@networkplumber.org; stefanha@redhat.com;
netdev@vger.kernel.org; apw@canonical.com; pebolle@tiscali.nl;
dan.carpenter@oracle.com
Subject: RE: [PATCH V4 4/7] Drivers: hv: vmbus: add APIs to register callbacks
to process hvsock connection

quoted

From: devel [mailto:driverdev-devel-bounces@linuxdriverproject.org] On

Behalf

quoted

Of Dexuan Cui
Sent: Thursday, July 30, 2015 18:20
To: David Miller <davem@davemloft.net>; KY Srinivasan

[off-list ref]

quoted

Cc: olaf@aepfle.de; gregkh@linuxfoundation.org; jasowang@redhat.com;
driverdev-devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
stephen@networkplumber.org; stefanha@redhat.com;

netdev@vger.kernel.org;

quoted

apw@canonical.com; pebolle@tiscali.nl; dan.carpenter@oracle.com
Subject: RE: [PATCH V4 4/7] Drivers: hv: vmbus: add APIs to register

callbacks to

quoted

process hvsock connection

quoted

From: David Miller
Sent: Thursday, July 30, 2015 6:27

From: Dexuan Cui
Date: Tue, 28 Jul 2015 05:35:11 -0700

quoted

With the 2 APIs supplied by the VMBus driver, the coming net/hvsock

driver

quoted

quoted

quoted

can register 2 callbacks and can know when a new hvsock connection is
offered by the host, and when a hvsock connection is being closed by

the

quoted

quoted

quoted

host.

This is an extremely terrible interface.

It's an opaque hook that allows on registry, and it's solve purpose
is to allow a backdoor call into a foreign driver in another module.

These are exactly the things we try to avoid.

Hi David,
Thanks a lot for your reviewing and the suggestion!

quoted

Why not create a real abstraction where clients register an object,
that can be contained as a sub-member inside of their own driver
private, that provides the callback registry mechanism.

Hi David,
Can you please have a look at my below questions?

I like your idea of a real abstraction. Your answer would definitely
help me to implement that correctly.

quoted

Please pardon me for my inexperience.
Can you please be a bit more specific?
I guess maybe you're referencing a common design pattern in the driver
code, so an example in some existing driver would be the best. :-)

"clients register an object " --
does the "clients" mean the hvsock driver?
and the "object" means the 2 callbacks?

IMHO, here the vmbus driver has to synchronously pass the 2 events
to the hvsock driver, so a "backdoor call into the hvsock driver" is
inevitable anyway?

e.g., in the path vmbus_process_offer() -> hvsock_process_offer(), the
return value of the latter is important to the former, because on error
the former needs to clean up some internal states of the vmbus driver

(that

quoted

is, the "goto err_deq_chan").

quoted

That way you can register multiple clients, do things like allow
AF_PACKET capturing of vmbus traffic, etc.

I thought AF_PACKET can only capture IP packetsor Ethernet frames.
Can it be used to capture AF_UNIX packet?
If yes, I suppose we can consider making it work for AF_HYPERV too,
if people ask for that.

Dexuan,

The notion of a channel on Hyper-V has been mapped to a device on Linux and
the mechanism we have
had of notifying the driver of the creation of the channel was through
registering this device with the kernel
(vmbus_device_create). The first exception to this was when we introduced
multi-channel support that broke
the assumption of this one to one mapping between the channel and Linux
device. In the case of the sub-channels,
we handled the  driver notification issue via the sub-channel callback that the
driver registers at the point of
opening the channel. Perhaps we could make the sub-channel handling
mechanism more generic to handle the case
of VMSOCK as well?

K. Y

Good suggestion!
Let me think this over and make a new patch.

Thanks,
-- Dexuan