Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2594026ybl; Thu, 29 Aug 2019 10:12:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqwIosEOF/RSkB54bz46t+VdOwR91MHGJle6fAVClpIR17Xnn7GOlQt94tD3+mKFnDId/ZAd X-Received: by 2002:a63:8ac3:: with SMTP id y186mr9286920pgd.13.1567098770994; Thu, 29 Aug 2019 10:12:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567098770; cv=none; d=google.com; s=arc-20160816; b=xYfix7GrjkfTpq7c6fhhI/refAC1moRTTLIXiKjhFeoSZVQLZaYJPyWZNspROkhNQj PZVt8mS/pI8PdBBpdeKvrRw3Uc5idcQrDdPLhSP7OumSSySmywdsyeOtCRL3UqDW/TsP 4qRSg9/RFUSziWK66cXIRmnqTOSZ3OBwxBBE+qIm8Xk29U4XKG6yv836LfE2yXw7kQoo gkWgEpyp/sppoaWXT7TS8jz1Nudu0eBsCg2axtnG3l2K2UKqJ59TKzvTlVJeWJ1xh/uW RAMVNox6Q81ZZq3V7IE68yssQh/MCueTiuwDYy7zIv0CTkfc7MZbOaiScUnOxJKtN0ad +DBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=HcK72yR7tvpZlsK0iCxAKtOjKUSLjESGOr3fmZ4YLOk=; b=RzAAAfZxlqdDoYT9Z9Rsg5AkCVYUw8Rxs/giuDixXZSet2AE6Xb9ivcO9bSE30VTC3 XjNqbBvnxwcHHO39JsbvGLKeejPi1xx0WoBa/m9DQ7UUjU+aJS5qJ4x8Nu4XS2iKYpuJ wUk4uePIMvhjvEfm/2sw9EaOJl/jBUZd71P3Wt7id6U1WB+6FU9kSS/A1Yl8noojgreH h5+X7EosionNo7nDuBoZEF2igOhLEi5Bu9vS63u9buwsemd96qA6ofEOAHGo5WMfioUE NrqZ7V5bzPbvFr12nAr8lMnJXYbGsbdHJAfm65KG87PGFnBc3dF3DT3UaEVw3s5RStS4 BGEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@volatile.bz header.s=default header.b=d0uj69xo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t25si2455143pgn.160.2019.08.29.10.12.35; Thu, 29 Aug 2019 10:12:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@volatile.bz header.s=default header.b=d0uj69xo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727794AbfH2RKL (ORCPT + 99 others); Thu, 29 Aug 2019 13:10:11 -0400 Received: from mx1.volatile.bz ([185.163.46.97]:38298 "EHLO mx1.volatile.bz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726739AbfH2RKL (ORCPT ); Thu, 29 Aug 2019 13:10:11 -0400 Received: from TheDarkness.local (unknown [IPv6:2600:6c5d:4200:1e2a:a077:9bc9:2f0:8eb9]) by mx1.volatile.bz (Postfix) with ESMTPSA id C72EB590; Thu, 29 Aug 2019 17:10:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=volatile.bz; s=default; t=1567098606; bh=S+o2J+owdblBkkWC9LHtU/ruSRBVwfwplyhgfA2Ch4E=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=d0uj69xoJI1nnoh2dMn+f6LJn2KwnUep+KVGsYedDdqJwM1oLZAg8nihhIcv3hfId Ocxad7wXbbWNCT8DDTmvaJViquVM/1eB+UiOOsxhkM73BKDYT7aOfv/S6KfFeOquCR +De78K+qoZKmkd3qZPOGRiLomi8bKD1bWiEFb0kY= Date: Thu, 29 Aug 2019 13:10:01 -0400 From: Dark To: Richard Weinberger Cc: Richard Weinberger , linux-kernel , anton ivanov , linux-um Subject: Re: [PATCH] um: Rewrite host RNG driver. Message-ID: <20190829130804.5e644540@TheDarkness> In-Reply-To: <1851013915.76434.1567092659763.JavaMail.zimbra@nod.at> References: <20190828204609.02a7ff70@TheDarkness> <20190829103628.61953f50@thedarkness.local> <1851013915.76434.1567092659763.JavaMail.zimbra@nod.at> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Well, it does not block but passing -EAGAIN directly back is not nice. > Or does the hw_random framework handle this? The framework is passing -EAGAIN to userspace which isn't very nice at all. Luckily, handling it is pretty trival so I went ahead and made an updated patch to address this. (I'm unsure of how to submit an update to my patch so I'll need a bit of guidence on this.) > Maybe our -EAGAIN handling is buggy. > That said I'm all for changing the driver to use the right framework > but please make sure that we don't drop useful stuff like -EAGAIN handlin= g. Most of the old code was pulled from the framework anyway so it's very unlikely that anything else would be dropped here. On Thu, 29 Aug 2019 17:30:59 +0200 (CEST), Richard Weinberger wrote: > ----- Urspr=C3=BCngliche Mail ----- > > Von: "Dark" > > An: "Richard Weinberger" , "linux-kernel"= > > CC: "richard" , "anton ivanov" , "linux-um" > > > > Gesendet: Donnerstag, 29. August 2019 16:36:28 > > Betreff: Re: [PATCH] um: Rewrite host RNG driver. =20 >=20 > > On Thu, 29 Aug 2019 15:26:24 +0200, Richard Weinberger > > wrote: =20 > >> So, you removed -EAGAIN handling, made everything synchronous, > >> and changed the interface.t > >> I'm not sure if this really a much better option. =20 > >=20 > > I should have been more clear here that I'm using the interfaces > > provided by `drivers/char/hw_random/core.c` for consistency with the > > other hardware RNG drivers and to avoid reimplementing stuff that's > > already there. =20 >=20 > I got this, and this is a good thing! > =20 > > It might be a bit hard to see in the diff, but I pass the file > > descriptor to `os_set_fd_async()` to prevent it from blocking. =20 >=20 > Well, it does not block but passing -EAGAIN directly back is not nice. > Or does the hw_random framework handle this? >=20 > > For the -EAGAIN handling, I'm passing it onto the caller. Since you > > mentioned it, It would be better to handle it in the driver itself > > so I'll update the patch to address that. > > =20 > >> Rewriting the driver in a modern manner is a good thing, but throwing = the > >> old one way with a little hand weaving just because of a unspecified i= ssue > >> is a little harsh. > >> Can you at lest provide more infos what problem you're facing with the > >> old driver? =20 > >=20 > > Most of it boiled down to it silently breaking if /dev/random on the > > host were to block for any reason, and there was the userspace tool > > requirement to properly make use of it. With that said, the interface > > was also inconsistent with the other hardware RNG drivers which would > > require a rewrite to address anyway. =20 >=20 > Maybe our -EAGAIN handling is buggy. > That said I'm all for changing the driver to use the right framework > but please make sure that we don't drop useful stuff like -EAGAIN handlin= g. >=20 > Thanks, > //richard