GSoC 2020: Implementation of OFW functions

[Christian Mauderer]

On 08/05/2020 17:26, Niteesh G. S. wrote:
> On Fri, May 8, 2020 at 11:43 AM Christian Mauderer
> <christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>> wrote:
> 
> 
>     On 07/05/2020 17:19, Niteesh G. S. wrote:
>     > On Thu, May 7, 2020 at 4:07 PM Sebastian Huber
>     > <sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>
>     > <mailto:sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>>> wrote:
>     >
>     >     On 07/05/2020 12:28, Niteesh G. S. wrote:
>     >
>     >     > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber
>     >     > <sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>
>     >     <mailto:sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>>
>     >     > <mailto:sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>
>     >     <mailto:sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>>>> wrote:
>     >     >
>     >     >     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.
>     >     >
>     >     >
>     >     > Ok. But what is the neatest way to hardwire this to the FDT
>     >     > implementation?
>     >     > One way as Christian mentioned would be to redefine OFW_*
>     functions to
>     >     > call the functions in ofw_fdt.c directly. Is there any other
>     way?
>     >
>     >     I would try to replace the function declarations in openfirm.h
>     with
>     >     inline functions which call the ofw_fdt.c functions.
>     >
>     >
>     > Should I proceed with the above method? or should I wait for others
>     > to comment?
>     > If I can proceed, the following is what I will be doing.
>     > 1) import openfirm.h and ofw_fdt.c into RTEMS.
>     > 2) Add ofw_fdt.h with functions declarations for functions in
>     ofw_fdt.c
>     > 3) Add necessary compile-time guards. This would include using
>     __rtems__
>     > preprocessor directive to avoid FreeBSD stuff and change the function
>     > definitions in ofw_fdt.c from static to non-static.
>     > Am I missing something? or is there any other way to do this?
> 
>     Maybe wait one or two more days for others to comment. For me the
>     direction sounds OK.
> 
>     You maybe can start thinking about where you want to import the
>     files to.
> 
> 
> Since this has scope for future development. I think we should put it in a 
> separate directory under cpukit/include/ofw for header files and cpukit/ofw
> for the source files. What do you think?
> 
> 

If you plan to prepare a FreeBSD sync (regardless whether you implement
it or someone else) another possibility could be to create a similar
directory structure like in libbsd.

Another directory could be ./cpukit/libmisc/rtems-fdt.

But your suggestion is also possible.

Maybe wait for some further input.

Best regards

Christian