GSoC 2020: Implementation of OFW functions

[Christian Mauderer]

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>> 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>>> 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.

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.