Re: [PATCH RFC 0/3] Drivers: hv: utils: re-implement the kernel/userspace communication layer

Radim Krčmář [off-list ref] writes:

2015-02-27 17:14+0100, Vitaly Kuznetsov:

quoted

This series converts kvp/vss daemons to use misc char devices instead of
netlink for userspace/kernel communication and then updates fcopy to be
consistent with kvp/vss.

Userspace/kernel communication via netlink has a number of issues:
- It is hard for userspace to figure out if the kernel part was loaded or not
  and this fact can change as there is a way to enable/disable the service from
  host side.

(Hm, this should be just a message to the userspace daemon, but netlink
 probably makes it complicated anyway.)

quoted

             Racy daemon startup is also a problem.

(Is it significantly worse than what we need to protect devices?)

quoted

- When the userspace daemon restarts/dies kernel part doesn't receive a
  notification.

(True, we could use a other-side-closed callback.)

With normal devices we can use e.g. udev/systemd machinery to start/stop
service on device hotplug/hotunplug (and these devices are actually
pluggable/unpluggable from host side) without any special code in
kernel/userspace parts and I'd like to use that.

quoted

- Netlink communication is not stable under heavy load.

(The message order changes?)

It is a disaster if it does (the whole transaction will get lost). Same
if any of these messages gets lost.

quoted

RFC: I'm a bit puzzled on how to split commits 1 and 2 avoiding breakages.

Split the userspace part -- it won't break bisects.

Sure if it simplifies the review.

And then, you could refactor drivers first ... the way we communicate
with userspace should have little impact on what the rest does (or how).
At first sight, there are three units, apart from glue,
 1) communication with host
 2) communication with userspace
 3) repacking of data between first two

With an API for userspace communication, the amount of code to replace
netlink could be lower and resulting patches definitely easier to
review.  (And with extra work, both ABIs could even live side-by-side ;)

Ok, thanks!

-- 
  Vitaly