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