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 _______________________________________________ devel mailing list [email protected] http://lists.rtems.org/mailman/listinfo/devel
