From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50205) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alwBq-0004Qh-9x for qemu-devel@nongnu.org; Fri, 01 Apr 2016 06:20:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1alwBm-0005aP-AN for qemu-devel@nongnu.org; Fri, 01 Apr 2016 06:20:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52141) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alwBm-0005aK-4i for qemu-devel@nongnu.org; Fri, 01 Apr 2016 06:20:26 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 003317AE9F for ; Fri, 1 Apr 2016 10:20:24 +0000 (UTC) Message-ID: <1459506023.7011.55.camel@redhat.com> From: Gerd Hoffmann Date: Fri, 01 Apr 2016 12:20:23 +0200 In-Reply-To: <1459503073-9684-1-git-send-email-lprosek@redhat.com> References: <1459503073-9684-1-git-send-email-lprosek@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] virtio-input: implement pass-through evdev writes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ladi Prosek Cc: qemu-devel@nongnu.org On Fr, 2016-04-01 at 11:31 +0200, Ladi Prosek wrote: > The write path for pass-through devices, commonly used for controlling > keyboard LEDs via EV_LED, was not implemented. This commit adds the > necessary plumbing to connect the status virtio queue to the host evdev > file descriptor. >=20 > Signed-off-by: Ladi Prosek > --- > Most of the new code has to do with handling EAGAIN/EWOULDBLOCK. I don't > believe that this will be happening in practise for local evdev devices. Agree. > Of course, all bets are off if fd is an arbitrary file, It can't be, it would fail the evdev ioctls. > with the event stream). So part of me would just do one best-effort > write and ignore all errors. I'm curious what you think.=20 Just do best-effort sounds reasonable to me. The code to handle EGAIN will just bitrot b/c it will never be used (and I guess it is untested too, or did you manage to provoke EGAIN somehow?) cheers, Gerd