GSoC 2020: Implementation of OFW functions

Sebastian Huber sebastian.huber at embedded-brains.de
Thu May 7 07:51:24 UTC 2020


On 07/05/2020 09:35, Niteesh G. S. wrote:

> This is what I was trying to convey in one of the previous mails.
> https://lists.rtems.org/pipermail/devel/2020-May/059717.html
> But in that mail, I was planning to replace KOBJLOOKUP.
> Should I start working on it? From the top of my mind, the following has
> to be done.
> 1) Import openfirm.c openfirm.h, ofw_fdt.c
> 2) Add ofw_fdt.h since all the functions in ofw_fdt are static.
> Should we also import ofw_if.h? Because that is where OFW_* functions
> are defined or just add a ofw_rtems_map.h which redefines them, instead
> of importing ofw_if.h?

The KOBJ stuff in the OFW support enables FreeBSD to have three 
different implementations of the OFW API which can be selected at runtime:

sys/powerpc/ofw/ofw_real.c
sys/dev/ofw/ofw_standard.c
sys/dev/ofw/ofw_fdt.c

In libbsd this is already short cut to the FDT implementation:

#ifndef __rtems__
static ofw_def_t    *ofw_def_impl = NULL;
#else /* __rtems__ */
#define    ofw_def_impl (&ofw_fdt)
#endif /* __rtems__ */

To me this looks like the KOBJ stuff was just used to enable some sort 
of object oriented programming. Do we need this flexibility at runtime 
in RTEMS? I would say no. I would hard wire this to the FDT 
implementation. If someone has a problem with it in the future, this 
decision can be readdressed.



More information about the devel mailing list