GSoC 2020: OFW Import To RTEMS License Issue
Niteesh G. S.
niteesh.gs at gmail.com
Sat Aug 8 08:47:38 UTC 2020
Hello,
So if I understand correctly, we will be having the following files
under RTEMS.
1) rtems-ofw.h / rtems-ofw.c These files will contain the RTEMS
friendly implementation of the OF interface.
For eg:
rtems_ofw_find_device(phandle_t node)
here I plan to implement all the functions that are required by the
original openfirm API and also few auxiliary functions which will be
helpful while implementing drivers.
2) openfirm.h This will provide the interface for libBSD and ported
drivers in RTEMS. And we will have to install openfirm.h for libBSD.
And also please remember that the openfirm.c in libBSD creates
xref to node handle structure for efficient translation. And the libBSD
drivers depend on this so if we remove these, the libBSD drivers will
not work. [1]
So we can not remove the openfirm.c completely.
[1]:
https://github.com/freebsd/freebsd/blob/c07cb50dbbf88e174e93f344a820fff68d24778d/sys/dev/ofw/openfirm.c#L119
On Fri, Aug 7, 2020 at 6:28 PM Gedare Bloom <gedare at rtems.org> wrote:
> On Fri, Aug 7, 2020 at 3:25 AM Niteesh G. S. <niteesh.gs at gmail.com> wrote:
> >
> > On Wed, Aug 5, 2020 at 2:16 AM Gedare Bloom <gedare at rtems.org> wrote:
> >>
> >> On Tue, Aug 4, 2020 at 12:38 PM Christian Mauderer <oss at c-mauderer.de>
> wrote:
> >> >
> >> > I think for this one we can only hope that the original author agrees
> to
> >> > a re-licensing. Otherwise it is only possible to add a replacement.
> >> >
> >>
> >> I suggest starting to make a plan for a clean room re-implementation.
> >> Ideally, one entity can extract the requirements from the current code
> >> or interface and write them up, so that another entity can
> >> re-implement the code from the written requirements. This is a little
> >> bit challenging in our situation, since the only entities that will
> >> write the code have already been exposed to the copyrighted version.
> >> (https://en.wikipedia.org/wiki/Clean_room_design) But we can still try
> >> our best!
> >>
> >> Interfaces are not, in general, copyright-protected. So, the person
> >> that captures the requirements can rely on the interface, but needs to
> >> write the requirements for implementing the interface in their own
> >> words.
> >
> >
> > You mentioned about providing an RTEMS friendly API for openfirm if we
> > want to implement openfirm in RTEMS and make the interface public to
> > avoid namespace pollution.
> > I have a few questions regarding this.
> >
> > 1) what about the imported drivers? The main reason for importing
> openfirm
> > into RTEMS was to reduce the number of modifications done to the imported
> > driver. So will we have two interfaces, one that is RTEMS-friendly and
> another
> > that provides the same interface as in openfirm?
> >
> > 2) What about libBSD? If we implement it in RTEMS we can remove it from
> > libBSD after thorough testing. This case is related to previous, libBSD
> expects
> > the interface provided by openfirm.h, you also mentioned about handling
> > FreeBSD-compat by providing macros
> > i.e: #define OF_finddevice rtems_ofw_find_device
> > This redefinition should be in RTEMS, right? because if we have it libBSD
> > we will need to have two redefinitions one in RTEMS to support the
> imported
> > drivers and others in libBSD.
>
> The redefinition approach can be implemented in a header file (e.g.,
> openfirm.h) included by drivers and by libbsd to address both of your
> points. As long as they aren't trying to access OF_finddevice by a
> linked/indirect function call which requires the symbol to exist.
> (Only a real problem for binary blobs, which could be solved by the
> application developer by providing instead some kind of openfirm.c
> that just calls the OF_* functions.)
>
> We just need to be a bit careful about the namespace. It is possible
> to add an OF_* interface, but we need to eliminate other options
> first.
>
> >>
> >>
> >> Gedare
> >>
> >> > On 04/08/2020 20:34, Niteesh G. S. wrote:
> >> > > ping.
> >> > >
> >> > >
> >> > > On Sat, Aug 1, 2020 at 2:11 PM Niteesh G. S. <niteesh.gs at gmail.com
> >> > > <mailto:niteesh.gs at gmail.com>> wrote:
> >> > >
> >> > >
> >> > >
> >> > > On Sat, Aug 1, 2020 at 1:37 AM Joel Sherrill <joel at rtems.org
> >> > > <mailto:joel at rtems.org>> wrote:
> >> > >
> >> > >
> >> > >
> >> > > On Fri, Jul 31, 2020 at 2:16 PM Niteesh G. S.
> >> > > <niteesh.gs at gmail.com <mailto:niteesh.gs at gmail.com>> wrote:
> >> > >
> >> > > Hello,
> >> > >
> >> > > In a recent review of these patches
> >> > >
> https://lists.rtems.org/pipermail/devel/2020-July/060653.html
> >> > > Gedare mentioned that we cannot use these patches with
> the
> >> > > current license. More details regarding the
> conversation can be
> >> > > found in the following archive.
> >> > >
> https://lists.rtems.org/pipermail/devel/2020-July/061000.html
> >> > >
> >> > > The following files have been ported to RTEMS to
> implement
> >> > > the OFW API.
> >> > > 1) openfirm.h -- BSD-4 License
> >> > > 2) openfirm.c -- BSD-4 License
> >> > > 3) ofw_fdt.c -- BSD-2 License
> >> > >
> >> > > The files with BSD4 cannot be used and Gedare suggested
> to
> >> > > check if we can remove the entire 4-clause cluster or
> remove
> >> > > clauses #3 and #4. I checked this along with the help of
> >> > > Christian
> >> > > and it seems that we can't remove those. Christian
> suggested
> >> > > that we can use the header file with the BSD-4 license
> to some
> >> > > extent but the source files to pose a problem. We also
> checked
> >> > > OpenBSD it has the same licensing.
> >> > >
> >> > >
> >> > > NetBSD appears to be the origin of the code and although I
> believe
> >> > > they did a largely blanket change from BSD-4, this code is
> old and
> >> > > normally, I would doubt they found the original submitter.
> Which
> >> > > would be odd in this case because this is his website with
> email:
> >> > >
> >> > > https://solfrank.net/Wolfgang/
> >> > >
> >> > > I have privately emailed to politely ask him to relicense
> it to
> >> > > BSD-2
> >> > > for use in RTEMS. And try to do that in a way that gets it
> on a
> >> > > path
> >> > > to get changed upstream.
> >> > >
> >> > > Hopefully this will solve it.
> >> > >
> >> > >
> >> > > Thanks for doing this Joel :).
> >> > >
> >> > >
> >> > >
> >> > > So we have come up with the following suggestions
> >> > > 1) Use the header files as it is.
> >> > >
> >> > >
> >> > > How close are you to being able to merge? Do we have time
> to let
> >> > > him answer?
> >> > >
> >> > >
> >> > > Yes, we do have a lot of time. All of my patches are based on
> the
> >> > > new build
> >> > > system so we won't be able to merge until the build system is
> >> > > merged. And
> >> > > also there are other things that have to be discussed regarding
> the
> >> > > patch.
> >> > >
> >> > >
> >> > >
> >> > > 2) Most OF_* functions defined in openfirm.c have 1:1
> mapping
> >> > > with the FDT implementation in ofw_fdt.c so there is a
> >> > > possibility
> >> > > to remove openfirm.c and only use openfirm.h and
> ofw_fdt.c.
> >> > > For those functions which don't have a 1:1 mapping, we
> can add
> >> > > an implementation in ofw_fdt.c. And remove the
> functions which
> >> > > don't have an FDT based implementation eg. OF_write,
> OF_open
> >> > > etc.
> >> > >
> >> > > Also please remember that these patches were created
> with a goal
> >> > > to import the OFW into RTEMS and remove them from
> libBSD so
> >> > > will using the above approach has a chance of breaking
> libBSD
> >> > > compatibility in the future?
> >> > >
> >> > >
> >> > > Yikes. That would mean having to create our own files that
> are
> >> > > compatible but don't have the license issue.
> >> > >
> >> > > And that our implementation is in a source transparent form
> that
> >> > > allows updates easily from the upstream source.
> >> > >
> >> > > If we can't get relicense permission, I think we have to
> rewrite the
> >> > > BSD-4 code and provide compatible versions. :(
> >> > >
> >> > >
> >> > > As of now, this seems to be the only option but let's hope for
> someone
> >> > > to come up with a better approach or get the license relaxed.
> >> > >
> >> > > Thanks,
> >> > > Niteesh
> >> > >
> >> > >
> >> > >
> >> > > Thanks,
> >> > > Niteesh.
> >> > > _______________________________________________
> >> > > devel mailing list
> >> > > devel at rtems.org <mailto:devel at rtems.org>
> >> > > http://lists.rtems.org/mailman/listinfo/devel
> >> > >
> >> > >
> >> > > _______________________________________________
> >> > > devel mailing list
> >> > > devel at rtems.org
> >> > > http://lists.rtems.org/mailman/listinfo/devel
> >> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200808/8a146501/attachment-0001.html>
More information about the devel
mailing list