Re: [PATCH] sys/tree.h: Removed

On Wed, Jul 17, 2024 at 10:52 AM Corinna Vinschen <[email protected]>
wrote:

> Hi Joel,
>
> On Jul 17 09:32, Joel Sherrill wrote:
> > Sorry. This sounds snippy in retrospect.
> >
> > Having sys/tree.h in libc puts us in a position where our libbsd package
> > depends on an arbitrary version from libc rather than the sys/tree.h
> which
> > comes with the FreeBSD version that each branch is based on. That makes
> > multiple RTEMS core developers nervous that we are introducing an
> > unnecessary mismatch. It may not cause problems but there is a risk and
> > invalidates one of the major reasons we use FreeBSD code for TCP/IP, NFS,
> > USB, etc.
> >
> > At this point, the implementation in FreeBSD 12 does not match newlib.
> > Folks have checked FreeBSD 13 and 14 which we will need to update to and
> > sys/tree.h does not match.
> >
> > This ignores the issue that RTEMS itself uses tree.h for some internal
> data
> > structures and we should have more configuration control over that.
> > Unintentional changes to the newlib version could impact RTEMS behavior
> or
> > performance in unexpected ways. In retrospect, adding this to newlib and
> > using it violated the rule we had long had for the core of RTEMS that we
> > should avoid using libc and other external libraries. Inside the OS
> proper,
> > we need to have more control and there may be odd restrictions that
> > wouldn't apply to applications.
> >
> > For RTEMS, Gedare added this as rtems/bsd-tree.h and changed the names to
> > put it into a namespace so it doesn't conflict with sys/tree.h.
> >
> > For RTEMS, the sys/tree.h file needs to come from the libbsd package so
> it
> > can be version mated with the FreeBSD kernel code in use on that branch.
> If
> > the libc has one version and libbsd has another, there is a conflict.
> >
> > Acting in good faith, I posted a patch to re-add it to newlib but I do
> not
> > know how to remove a standard lib/include file for a target. We really do
> > not want it installed from libc.
> >
> > Hopefully this is a little clearer.
>
> This is fine, but still, keep in mind that you're creating a potential
> breakage by removing sys/tree.h entirely for projects using it.
>
> Given that Sebastian added the file in 2015, Cygwin came with sys/tree.h
> since the next release after that.
>
> There are certain projects out there actually using sys/tree.h if it is
> available.  For instance, tmux, OpenBSD's file, and quite a few others.
> In fact, I have no idea how many of the ~4000 packages on Cygwin (apart
> from tmux) use that file.
>
> Therefore just removing the file is kind of dangerous and could either
> break a package or change its behaviour in subtil ways.
>
> Having said that...
>
> Given you have a workaround for RTEMS, we can just resurrect sys/tree.h,
> but that's a bit underwhelming.
>
> While I can easily imagine that sys/tree.h from FreeBSD got new APIs, I
> can't believe that it actually broke the existing API in a
> backward-incompatible way.
>
> Either way, it would be nice if we could get an updated version of this
> file rather than just the old version.  Would you mind?
>

Sebastian Huber is the only one who has done any maintenance on this
file so he should update it.

How can a common header be removed for a target that doesn't want it?

--joel

>
>
> Thanks,
> Corinna
>
>