On Wed, Feb 24, 2021 at 11:55 AM Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > > On 24/02/2021 19:49, Gedare Bloom wrote: > > > On Wed, Feb 24, 2021 at 11:36 AM Sebastian Huber > > <sebastian.hu...@embedded-brains.de> wrote: > >> On 24/02/2021 19:22, Gedare Bloom wrote: > >> > >>> On Wed, Feb 24, 2021 at 6:57 AM Sebastian Huber > >>> <sebastian.hu...@embedded-brains.de> wrote: > >>>> This patch set adds the new directives rtems_get_build_hash() and > >>>> rtems_get_target_hash() which can be used to differentiate test suite > >>>> results. See also the following discussion: > >>>> > >>>> https://lists.rtems.org/pipermail/devel/2020-November/063226.html > >>>> > >>>> Sebastian Huber (10): > >>>> build: Generate build hash > >>>> rtems: Add rtems_get_build_hash() > >>>> libtest: Report build hash > >>>> score: Add _IO_Base64url() > >>>> score: Add Hash Handler > >>>> rtems: Add rtems_get_target_hash() > >>>> Add system initialization step for target hash > >>>> bsps: Add default rtems_get_target_hash() > >>>> libtest: Report target hash > >>>> libtest: Print SHA256 hash in base64url > >>>> > >>> Is there a good reason to use SHA256 over a lighter weight algorithm? > >>> I guess I wonder about the overhead and value of using it. > >>> > >>> We don't need cryptographic security here, we just need a reasonably > >>> non-colliding checksum. The speed of hashing will matter for running > >>> testsuites. > >> SHA256 is currently the best algorithm for 32-bit targets we have in the > >> RTEMS sources. It is also selected for the next Git hash. I don't think > >> the time to calculate the hash really matters and I want to avoid any > >> discussions if MD5 is sufficient or not. > >> > > OK, from a code existence argument this is fine. I could even see a > > possibility to fold in the source code hashes in the future to make a > > "secure" checksum that can be verified at boot-time. > > > If the hash algorithm turns out to be an issue, we can change it. From > an API point of view it doesn't matter. It just has to be a some string. > OK I see that, this is fine. Thanks
> -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
