On Fri, Aug 7, 2020 at 3:25 AM Niteesh G. S. <niteesh...@gmail.com> wrote: > > On Wed, Aug 5, 2020 at 2:16 AM Gedare Bloom <ged...@rtems.org> wrote: >> >> On Tue, Aug 4, 2020 at 12:38 PM Christian Mauderer <o...@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...@gmail.com >> > > <mailto:niteesh...@gmail.com>> wrote: >> > > >> > > >> > > >> > > On Sat, Aug 1, 2020 at 1:37 AM Joel Sherrill <j...@rtems.org >> > > <mailto:j...@rtems.org>> wrote: >> > > >> > > >> > > >> > > On Fri, Jul 31, 2020 at 2:16 PM Niteesh G. S. >> > > <niteesh...@gmail.com <mailto:niteesh...@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@rtems.org <mailto:devel@rtems.org> >> > > http://lists.rtems.org/mailman/listinfo/devel >> > > >> > > >> > > _______________________________________________ >> > > devel mailing list >> > > devel@rtems.org >> > > http://lists.rtems.org/mailman/listinfo/devel >> > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
