From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) by sourceware.org (Postfix) with ESMTPS id DA3FF386C5BB for ; Thu, 30 Jun 2022 07:58:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DA3FF386C5BB Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=opteya.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=opteya.com Received: from [IPV6:2a01:e35:39f2:1220:7e41:6899:9adb:741d] (unknown [IPv6:2a01:e35:39f2:1220:7e41:6899:9adb:741d]) by smtp4-g21.free.fr (Postfix) with ESMTPS id E60AA19F5AD for ; Thu, 30 Jun 2022 09:58:09 +0200 (CEST) Message-ID: <95604aa1-4640-b325-af58-2e669e12e2c7@opteya.com> Date: Thu, 30 Jun 2022 09:58:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v8 9/9] manual: Add documentation for arc4random functions Content-Language: fr-FR To: libc-alpha@sourceware.org References: <20220629213428.3065430-1-adhemerval.zanella@linaro.org> <20220629213428.3065430-10-adhemerval.zanella@linaro.org> <1471BD6A-8680-41E9-9FE5-B1DC45940264@linaro.org> From: Yann Droneaud Organization: OPTEYA In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.0 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_SOFTFAIL, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2022 07:58:12 -0000 Hi, Le 30/06/2022 à 00:05, Noah Goldstein via Libc-alpha a écrit : > On Wed, Jun 29, 2022 at 2:53 PM Adhemerval Zanella > wrote: >> >> >>> On 29 Jun 2022, at 18:45, Noah Goldstein wrote: >>> >>> On Wed, Jun 29, 2022 at 2:36 PM Adhemerval Zanella via Libc-alpha >>> wrote: >>>> --- >>>> manual/math.texi | 45 +++++++++++++++++++++++++++++++++++++++++++++ >>>> 1 file changed, 45 insertions(+) >>>> >>>> diff --git a/manual/math.texi b/manual/math.texi >>>> index 477a18b6d1..ab96726e57 100644 >>>> --- a/manual/math.texi >>>> +++ b/manual/math.texi >>>> @@ -1447,6 +1447,7 @@ systems. >>>> * ISO Random:: @code{rand} and friends. >>>> * BSD Random:: @code{random} and friends. >>>> * SVID Random:: @code{drand48} and friends. >>>> +* High Quality Random:: @code{arc4random} and friends. >>>> @end menu >>>> >>>> @node ISO Random >>>> @@ -1985,6 +1986,50 @@ This function is a GNU extension and should not be used in portable >>>> programs. >>>> @end deftypefun >>>> >>>> +@node High Quality Random >>>> +@subsection High Quality Random Number Functions >>>> + >>>> +This section describes the random number functions provided as a GNU >>>> +extension, based on OpenBSD interfaces. >>>> + >>>> +@Theglibc{} uses kernel entropy obtained either through @code{getrandom} >>>> +or by reading @file{/dev/urandom} to seed and periodically re-seed the >>>> +internal state. A per-thread data pool is used, which allows fast output >>>> +generation. >>>> + >>> Are we committing to per-thread data pools? I thought there were ideas to >>> use rseq. >> For this version yes, since it works on all supported kernels (even for the >> ones without getentropy support) and on all architectures. I do not know how >> feasible it would be to implement per-cpu caches along with rseq and it would >> require a fallback for older kernel (most likely a per-thread cache as this >> version), although it might be future improvement. > I guess do we want to explicitly say per-thread buffer if we may want > to experiment > with something else? > > Just seems like the kind of thing that might make it impossible to re-implement > another way. > > What about something like: > > "The data-pool is implemented to minimize cross-core contention > allowing fast output generation"? "Each thread has its own independant random stream" -- Yann Droneaud OPTEYA