New Build System: Can't include headers

[Christian Mauderer]

On 29/06/2020 19:39, Sebastian Huber wrote:
> On 29/06/2020 17:13, Niteesh G. S. wrote:
> 
>> 2) Is it possible to have two same files one in RTEMS and other in
>> RTEMS-libBSD
>> without collision? At least with different install paths?
>> For eg: The openfirm.h in RTEMS under something like
>> libfreebsd/dev/ofw/openfirm.h
>> And the open in libBSD as it is done currently.
>> So this way we can include the RTEMS variant with
>> #include <libfreebsd/dev/ofw/openfirm.h>
> Why can't we use your new stuff also in libbsd? We should avoid
> duplication.

Hello Sebastian,

as far as possible, that is a good idea. For example for ti_cpuid.h:

https://github.com/gs-niteesh/rtems/blob/397a3b5b961f852f47ade00dcae389c4b160c720/cpukit/libfreebsd/freebsd/sys/arm/ti/ti_cpuid.h

That one should replace the one in libbsd.

But I think that it will be hard to do that for some other headers. It
will become tricky for everything that uses more complex interfaces like
the openfirmware bus. Either we import a _lot_ of stuff from FreeBSD
into RTEMS to get a libbsd compatible bus system. Or we have an
incompatible system where the headers might differ.

It's really hard to find a balance. In an earlier discussion (I think
with Chris or Gedare) the direction for this new subsystem was to pull
in only very few basic stuff so that we can use low-level drivers like
pinmux or simple serial drivers. That also means that some of the
software parts will be called very early.

For example the Pinmux in BBB should be already set up before all other
drivers are initialized. Therefore Niteesh added it as a SYSINIT during
RTEMS_SYSINIT_BSP_PRE_DRIVERS. That means that multithreading isn't
started yet which made trouble with some reentrant standard library
functions. But these functions are sometimes used in FreeBSD code.

I think that porting and integrating big (100% libbsd compatible) parts
will be a huge effort. Therefore I suggested to keep the systems separate.

Do you think importing bigger parts would be the better solution?

Best regards

Christian