From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id BFF95A00C4; Thu, 23 Apr 2020 19:43:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6C1E31C22D; Thu, 23 Apr 2020 19:43:28 +0200 (CEST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by dpdk.org (Postfix) with ESMTP id 73A551C1F7 for ; Thu, 23 Apr 2020 19:43:27 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id f19so7331310iog.5 for ; Thu, 23 Apr 2020 10:43:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dVz6htB7p6tWglmemYzgtuG1M9lF2Df75P8ACyYxDcQ=; b=AmER9RbKD8BWJ7FtCOFg7JMwMoe5ebl4FF0Cljt55PxcJu8DO9AB1YsxYPK7uZ2JEb y64/VKLBraUQEsZVi1CicQfMSTXClCGIepD8kGrTP70h8hLvEhe4dWWkuaheyp6OhdOS 4N1AKHdnr7FTf/2TzmmD9tzFlOATG7qSas1+opK2xrwMs8ugHxHgNZNvDOECi9IPSRxp sUVNU0Mz3zu2Cv15zX6AngOKqtbHCJyM4TrtHAOJcnmW5lhVRg0RkPekF7X5BcdAWxuW KO9FoRjdiXdKyiDXHVX4yMpdc5ZRruftt28Y8njXK4WzlN962nKxPri10kmS5yujOvfW 4J3A== X-Gm-Message-State: AGi0PuZTB+3ALFCzfS5kYw9J9U/qXU8z+vLGwNxSAm8gIk6tSkWyv8d2 5rof+MspYm29UWLGxsu6vmRhYvQSk5sbl0EivUQ= X-Google-Smtp-Source: APiQypIRSAe8i0VhNG0TdGHqSu5Bxd8pHig6oQxD9IaUyTBC7qBwqwzu4/u8yt6QY0nsvaoTd1X7KsVisXq09YE1TbY= X-Received: by 2002:a02:cbba:: with SMTP id v26mr4201540jap.14.1587663806854; Thu, 23 Apr 2020 10:43:26 -0700 (PDT) MIME-Version: 1.0 References: <20200421195446.1730-1-dg@adax.com> <20200422234255.7066-1-dg@adax.com> <20200422234255.7066-3-dg@adax.com> <20200422193939.20841234@hermes.lan> In-Reply-To: <20200422193939.20841234@hermes.lan> From: Dan Gora Date: Thu, 23 Apr 2020 14:42:51 -0300 Message-ID: To: Stephen Hemminger Cc: dev@dpdk.org, =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , David Marchand , Jerin Jacob Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v4 2/2] eal: emulate glibc getentropy for initial random seed X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Apr 22, 2020 at 11:39 PM Stephen Hemminger wrote: > > On Wed, 22 Apr 2020 20:42:54 -0300 > Dan Gora wrote: > > > + fd = open("/dev/urandom", O_RDONLY); > > + if (fd < 0) { > > + errno = ENODEV; > > + return -1; > > + } > > + > > + end = start + length; > > + while (start < end) { > > + bytes = read(fd, start, end - start); > > + if (bytes < 0) { > > You are overdoing the complexity here. More error handling is not better. I've definitely never heard that expression before! > 1. This should only be called once at startup EINTR is not an issue then > 2. The amount requested is always returned when using urandom (see man page for random(4)) > > The O_NONBLOCK flag has no effect when opening /dev/urandom. When calling > read(2) for the device /dev/urandom, reads of up to 256 bytes will return as > many bytes as are requested and will not be interrupted by a signal handler. > Reads with a buffer over this limit may return less than the requested number > of bytes or fail with the error EINTR, if interrupted by a signal handler. I didn't just make this up out of whole cloth... This code was lifted, almost verbatim, from the glibc implementation of getentropy(), which is the function that we are trying to emulate: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getentropy.c;h=1778632ff1f1fd77019401c3fbaa164c167248b0;hb=92dcaa3e2f7bf0f7f1c04cd2fb6a317df1a4e225 I assumed that they added this error handling for a reason. Yes, since this function is only called once at startup EINTR should not be an issue, but if we need to add __rte_getentropy() as a generic, exported interface later, that error case would already be taken care of. thanks dan