public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Joel Sherrill <joel@rtems.org>
To: Sebastian Huber <sebastian.huber@embedded-brains.de>
Cc: newlib@sourceware.org
Subject: Re: [PATCH] sys/tree.h: Removed
Date: Thu, 20 Jun 2024 17:21:04 -0500	[thread overview]
Message-ID: <CAF9ehCWMYskVEuanFTwspE+w1U5RtsrWYgmtf0yq0PsBODdwtw@mail.gmail.com> (raw)
In-Reply-To: <29ad23ba-5235-4830-82e4-8ceb941e7889@embedded-brains.de>

[-- Attachment #1: Type: text/plain, Size: 2029 bytes --]

On Thu, Jun 20, 2024 at 4:13 AM Sebastian Huber <
sebastian.huber@embedded-brains.de> wrote:

> On 18.06.24 22:25, Joel Sherrill wrote:
> > This file was from a specific older FreeBSD version. There have been
> > multiple changes to this file with FreeBSD 14 including breaking
> > changes to the file.
>
> What kind of breaking changes did you observe in the FreeBSD 14 version
> of <sys/tree.h>? I see no breaking API changes. FreeBSD changed the
> implementation to use rank-balanced trees instead of red-black trees,
> but this should not have resulted in API breaks (the ABI changed though).
>

This creates a conflict between the libc and rtems-libbsd versions. When
both are installed, the header installed by libbsd results in different code
than the version RTEMS was compiled with.

Using this internally in RTEMS, we opened ourselves to external changes
impacting the score implementation of rbtree.  This leaves us
open to external changes having an impact on performance.
We should take on the preferred implementation inside the score of
RTEMS so we have control. We will end up having to do something
with the file name and name space.

This actually violated a core development principle for RTEMS and
we should have spotted this long ago. Everything in the score and
"bottom" of RTEMS should not depend on libc.

We need to control the implementation used internal to RTEMS.
Realizing that it was not up date in newlib just triggered the realization
that we should not have been using it.

--joel


> --
> embedded brains GmbH & Co. KG
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber@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/
>

  reply	other threads:[~2024-06-20 22:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-18 20:25 Joel Sherrill
2024-06-20  9:13 ` Sebastian Huber
2024-06-20 22:21   ` Joel Sherrill [this message]
2024-06-21  1:30     ` Chris Johns

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAF9ehCWMYskVEuanFTwspE+w1U5RtsrWYgmtf0yq0PsBODdwtw@mail.gmail.com \
    --to=joel@rtems.org \
    --cc=newlib@sourceware.org \
    --cc=sebastian.huber@embedded-brains.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).