GSoC 2020: Implementation of OFW functions
Gedare Bloom
gedare at rtems.org
Fri May 8 21:05:57 UTC 2020
On Fri, May 8, 2020 at 9:34 AM Christian Mauderer <oss at c-mauderer.de> wrote:
>
>
> 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.
>
This thread got a bit massive. It might be nice to refactor to a clean
mail thread :) I'd be agreeable to the idea of a sync to freebsd for
external sources that we import to rtems.git, but the management of
that sync has to be done carefully and we must keep in mind the needs
of low-end targets. I wouldn't like to see too much feature creep from
freebsd into rtems in order to support some things meant for only a
few relatively resource-rich boards.
If we do this sync, I think it should be handled as a single
subdirectory that syncs all imports simultaneously. I don't want to be
managing several different imports from various versions of upstream
freebsd sources. This would mean something more like cpukit/libfreebsd
maybe. Avoid using libbsd, and I think calling it by the upstream name
is a good way to proceed. The design and planned implementation of
this process needs to be fleshed out and discussed on the ml, and
maybe a simple preliminary example/use case (fdt is ok) would be good
to sketch, as well as possible future additions and how they would be
incorporated.
I also need to be convinced that this code must be pulled into
rtems.git and can't be compiled/linked separately.
Gedare
> Best regards
>
> Christian
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
More information about the devel
mailing list