From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754303AbbCBNdc (ORCPT ); Mon, 2 Mar 2015 08:33:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58870 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752046AbbCBNda (ORCPT ); Mon, 2 Mar 2015 08:33:30 -0500 From: Vitaly Kuznetsov To: Radim =?utf-8?B?S3LEjW3DocWZ?= Cc: "K. Y. Srinivasan" , devel@linuxdriverproject.org, Haiyang Zhang , linux-kernel@vger.kernel.org, Dexuan Cui , Greg Kroah-Hartman , linux-api@vger.kernel.org Subject: Re: [PATCH RFC 0/3] Drivers: hv: utils: re-implement the kernel/userspace communication layer References: <1425053665-635-1-git-send-email-vkuznets@redhat.com> <20150227210744.GA11904@potion.brq.redhat.com> Date: Mon, 02 Mar 2015 14:33:20 +0100 In-Reply-To: <20150227210744.GA11904@potion.brq.redhat.com> ("Radim \=\?utf-8\?B\?S3LEjW3DocWZIidz\?\= message of "Fri, 27 Feb 2015 22:07:44 +0100") Message-ID: <87a8zvjzhb.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Radim Krčmář writes: > 2015-02-27 17:14+0100, Vitaly Kuznetsov: >> 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.) > >> Racy daemon startup is also a problem. > > (Is it significantly worse than what we need to protect devices?) > >> - 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. > >> - 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. >> 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