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

Joel Sherrill <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <CAF9ehCVPJ8hYqmS4e73bMjVyLf3sJS_ewCOKgLOZ7Nb-rRrdCQ@mail.gmail.com>
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.

--joel

On Tue, Jul 16, 2024 at 6:31 PM Joel Sherrill <[email protected]> wrote:

>
>
> On Tue, Jul 16, 2024 at 4:39 AM Corinna Vinschen <[email protected]>
> wrote:
>
>> On Jul 16 07:41, Sebastian Huber wrote:
>> > ----- Am 18. Jun 2024 um 22:25 schrieb Joel Sherrill [email protected]:
>> >
>> > > 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. Including this file as part of newlib results
>> > > in not always having the correct version of sys/tree.h for any
>> > > specific software. RTEMS will manage its use of this file outside
>> > > of newlib.
>> >
>> > This file is not RTEMS-specific. I think removing this file would have
>> > required a general approval.
>>
>> I agree with Sebastian.
>>
>> One point to think of is that newlib headers are automatically part of a
>> Cygwin installation if they are not overrode by a Cygwin-specific header
>> of the same name and path.  Just removing that file has the potential
>> to break some Cygwin package relying on the existence of that file.
>>
>
> The presence of this as a unique libc file has already caused concerns
> because it differs with the versions from FreeBSD.
>
>>
>> So just removing files in the generic header path should always be
>> discussed first.
>>
>
> Sorry, If you want to re-add it feel free. It is commonly available
> but not part of any standard.
>
> --joel
>
>
>>
>>
>> Thanks,
>> Corinna
>>
>>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.