[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    Re: [OE-Core][master][langdale][kirkstone][PATCH v2] rng-tools: backport patch to adjust jitterentro
From:       "Randy MacLeod" <randy.macleod () windriver ! com>
Date:       2022-11-29 22:28:19
Message-ID: ea2e31cb-21e1-0c04-9542-d8b8f0e58040 () windriver ! com
[Download RAW message or body]

On 2022-11-29 10:52, Ross Burton via lists.openembedded.org wrote:
> On 28 Nov 2022, at 09:25, Alexander Kanavin via lists.openembedded.org \
> <alex.kanavin=gmail.com@lists.openembedded.org> wrote:
> > 
> > On Sun, 27 Nov 2022 at 14:39, Xiangyu Chen
> > <xiangyu.chen@eng.windriver.com> wrote:
> > > * add libgcc in RDEPENDS flag to solve testing failed in \
> > > core-image-full-cmdline +RDEPENDS:${PN} = "libgcc"
> > 
> > This needs to be better investigated first. The change looks like
> > solving the symptom, but not the actual issue.
> 
> It's not uncommon: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10954

While it would be good to solve the general case of libgcc dependency 
mentioned in that case,
I do wonder if the original issue that Xiangyu saw, goes away if we 
_only_ add:

  +RDEPENDS:${PN} = "libgcc"

to rngtools without added the upstream timeout after 5 seconds or
it the dependency is only required with the patch?

Xiangyu ?


I also don't like the arbitrary timeout and I'd like references
from the board vendor that explains that proper RNG isn't supported!
( I'm not a BSP person so this may be optimistic! )


Note that there is a follow-up patch to make the timeout configurable, 
see below.
If we take the original patch, we should take both and require that the 
BSP tune
the timeout. We'll get this behaviour once the patches are integrated 
into a release
so we might as well figure out if we're going to:
  1. have a tuning policy,
  2. continually revert the patch or
  3. actually get to the root cause of the problem (by working with 
board vendors I expect).


../Randy

commit 6e14b8bd491b3f94f60f36748959e0ae7d7c1f95
Author: Dan Horák <dan@danny.cz>
Date:   Mon Jul 18 04:47:41 2022

     rngd_jitter: make timeout configurable

     The current default 5 sec timeout can be too short in some situations
     (eg. slow hardware). Introduce a command line option (jitter:timeout)
     to make the value configurable. Increasing the default timeout is not
     desirable, because it might slow down system startup when there are
     other entropy sources.

     Signed-off-by: Dan Horák <dan@danny.cz>

commit c29424f10a0dcbd18ac25607fa1c81c18a960e81 (origin/jitter-init)
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Mon May 16 13:38:54 2022

     Adjust jitterentropy library to timeout/fail on long delay

     When running rngd -l its possible, on platforms that have low jitter
     entropy to block for long periods of time.  Adjust jitter to timeout on
     init after 5 seconds in the event it takes to long to gether jitter
     entropy

     Also while we're at it, I might have a build solution for the presence
     of internal timers.  When jitterentropy is built without internal
     timers, jent_notime_init is defined publically, but when it is built
     with timers, its declared as a static symbol, preenting resolution, so
     we can test to see if the function exists.  If it does we _don't_ have
     notime support. The logic is a bit backwards, but i think it works


> 
> Ross
> 
> 
> 
> 
> 

-- 
# Randy MacLeod
# Wind River Linux



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173988): https://lists.openembedded.org/g/openembedded-core/message/173988
Mute This Topic: https://lists.openembedded.org/mt/95288451/4454766
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [openembedded-core@marc.info]
-=-=-=-=-=-=-=-=-=-=-=-



[prev in list] [next in list] [prev in thread] [next in thread]