From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756040AbbCCTrS (ORCPT ); Tue, 3 Mar 2015 14:47:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34447 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752805AbbCCTrQ (ORCPT ); Tue, 3 Mar 2015 14:47:16 -0500 Date: Tue, 3 Mar 2015 20:47:07 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Vitaly Kuznetsov 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 1/3] Drivers: hv: kvp: convert userspace/kernel communication to using char device Message-ID: <20150303194707.GG25123@potion.brq.redhat.com> References: <1425053665-635-1-git-send-email-vkuznets@redhat.com> <1425053665-635-2-git-send-email-vkuznets@redhat.com> <20150227202715.GF2034@potion.brq.redhat.com> <87pp8qif00.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87pp8qif00.fsf@vitty.brq.redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2015-03-03 10:53+0100, Vitaly Kuznetsov: > Radim Krčmář writes: > > 2015-02-27 17:14+0100, Vitaly Kuznetsov: > >> Re-implement the communication using misc char device. Use ioctl to do > >> kernel/userspace version negotiation (doesn't make much sense at this moment > >> as we're breaking backwards compatibility but can be used in future). > > > > The ioctl is used too creatively for my liking: as an out-of-band > > communication that is required after the main channel has been opened. > > It would be simpler to inject the version into first x bytes of the > > stream, making a read() after open() mandatory. > > We need to perform a handshake - kernel part sends its version and > receives daemon's version. (We could also design a backward-compatible protocol, which should be possible for an application this simple, but keeping options is wise.) > We can definitelly pack everything in the > data stream but why do we need to avoid ioctls? I think it is better if the kernel sends its version (set of features) first, so it would be just a simple two-way handshake. Kernel-initiated communication is not possible over ioctl and it doesn't give extra options for handshake either. > It seems to me the > handshake we're performing here belongs to a 'control' stream, not > 'data' stream. Handshake makes sense after we open the device and before any 'data' can appear on it, so multiplexing the same carrier also prevents a lot of stupid cases, like ioctls from different applications. Not to mention that asynchronicity itself has a fairly bad record. (I don't really understand the difference between 'control' and 'data'.)