On 08/05/2020 17:26, Niteesh G. S. wrote: > On Fri, May 8, 2020 at 11:43 AM Christian Mauderer > <christian.maude...@embedded-brains.de > <mailto:christian.maude...@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.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de> > > <mailto:sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@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.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de> > > <mailto:sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de>> > > > <mailto:sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de> > > <mailto:sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel