On Sat, Aug 8, 2020 at 2:48 AM Niteesh G. S. <niteesh...@gmail.com> wrote: > > 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. > yes
> 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. > ok. Another thought occurs, you can dig through the bsd history and find the original source file with the 4-BSD clause. That will let you know what is covered by that license. It may be a lot of this code has been rewritten or is under the newer 2-BSD with the other contributor's licensing. > > [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 <ged...@rtems.org> wrote: >> >> 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
