<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Does it matter that there is a new stable release coming from the LwIP people very soon now?<div class=""><br class=""></div><div class="">As a target user of the system, I can live with pulling STM’s HAL out of the RTEMS tree completely and adding it back in myself. The HAL calls in RTEMS are no different than the fight that just happened between Oracle and Google re: the Java API (Oracle lost). I can add in the HAL for my processor without affecting others wishing to put ST’s code on a clone processor from Giga Devices. </div><div class=""><br class=""></div><div class="">As for LwIP, could you pull the code from the LwIP repo instead of ST’s repo(???) </div><div class=""><br class=""></div><div class="">My 0.02CAD,</div><div class=""><br class=""></div><div class="">Andrei<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 2021-September-09, at 10:30, Shiro <<a href="mailto:rt9f.3141@gmail.com" class="">rt9f.3141@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi, Robin,<div class=""><br class=""></div><div class="">There are a number of ways to manage this, but the first thought that comes to my mind is:</div><div class=""><br class=""></div><div class="">* Priority #1: protect the license-integrity of the RTEMS src tree. That means any “license contamination” must be quarantined.</div><div class="">I like the way NetBSD (BSD) handles source covered by some foreign (GNU, etc.) license. They keep the src in a separate dir and further sub dirs by license.</div><div class=""><br class=""></div><div class="">* Priority #2: support the “difficult” platform. Try to make the build as transparent and simple as for other “easy” platforms. The magic here would be, I think, a recipe in the Makefile to build the STM32 lwIP source file, then compile…. The Makefile would need to know where the patch is…</div><div class=""><br class=""></div><div class="">In this way, one could remove the “foreign-license” dir tree and know the RTEMS tree is clean.</div><div class=""><br class=""></div><div class="">Just my $0.02.</div><div class=""><br class=""></div><div class="">Best regards,</div><div class="">-Shiro</div><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 9, 2021, at 3:01 AM, Robin Mueller <<a href="mailto:robin.mueller.m@gmail.com" class="">robin.mueller.m@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">Hi Shiro,<br class="">
</p>
<div class="moz-cite-prefix">So you mean, retain the STM32 file
unchanged in the source tree and then applying the patch? Or copy
it from somewhere and then apply the patch? <br class="">
<br class="">
I thought of that option as well.<br class="">
</div>
<div class="moz-cite-prefix">The only issue I see here is that I
merged the (example) files provided by STM32 so that one file can
be used for every lwIP API. I managed to have the same files for
alle three APIs this way, which is the cleaner solution in my
opinion. But I guess I could just take the base files for the Raw
API provided by STM32, create the patch to add support for all
other APIs and add all other tweaks required for RTEMS, and then
provide that patch somewhere.</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">Kind Regards<br class="">
Robin<br class="">
</div>
<div class="moz-cite-prefix">On 08.09.21 21:05, Shiro wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:B96EE847-2FBC-4920-911B-5DD22EC945CF@gmail.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
Hi, Robin,
<div class=""><br class="">
</div>
<div class="">Would it be possible to retain the STM32 code, but
carve out the “contaminated” lwIP code into a patch file. Then
RTEMS code base remains “clean” and if I, any user, chose to
enable lwIP on STM32, I could do so by applying that patch. I’d
contaminate my src tree, but that’d be my responsibility and in
any case, I’d be compliant (target is after all an STM32…).</div>
<div class=""><br class="">
</div>
<div class="">The “patch trick” to manage license contamination
has worked well for others in the past.</div>
<div class=""><br class="">
</div>
<div class="">Cheers,</div>
<div class="">-Shiro<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Sep 8, 2021, at 11:51 AM, Robin Müller <<a href="mailto:robin.mueller.m@gmail.com" class="" moz-do-not-send="true">robin.mueller.m@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">Hi,</div>
<div class=""><br class="">
</div>
<div class="">Unfortunately, there was no other reply to
the request.</div>
<div class=""><br class="">
</div>
<div class="">Easiest solution would be to exclude the
STM32 code completely out of RTEMS code for now. I can
host it as example code in a personal repository.</div>
<div class="">But then I might have to change the
architecture of the lwIP code again which provided
some building blocks to make porting/using it easier.</div>
<div class=""><br class="">
</div>
<div class="">Kind Regards<br class="">
</div>
<div class="">Robin<br class="">
</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, 5 Aug 2021 at
17:00, Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank" class="" moz-do-not-send="true">gedare@rtems.org</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">STM is not going to
fix their Ultimate Liberty License at this time.<br class="">
<a href="https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010" rel="noreferrer" target="_blank" class="" moz-do-not-send="true">https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010</a><br class="">
<br class="">
So, we need to avoid using their example codes.<br class="">
<br class="">
On Wed, Jun 9, 2021 at 12:16 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank" class="" moz-do-not-send="true">gedare@rtems.org</a>>
wrote:<br class="">
><br class="">
> I joined the Issue. Thanks for working on this.<br class="">
><br class="">
> On Wed, Jun 9, 2021 at 11:30 AM Robin Müller <<a href="mailto:robin.mueller.m@gmail.com" target="_blank" class="" moz-do-not-send="true">robin.mueller.m@gmail.com</a>>
wrote:<br class="">
> ><br class="">
> > I posted a reply but I think it did not go
through. Will post it now.<br class="">
> ><br class="">
> > Kind Regards<br class="">
> > Robin<br class="">
> ><br class="">
> > On Wed, 9 Jun 2021 at 18:31, Robin Müller
<<a href="mailto:robin.mueller.m@gmail.com" target="_blank" class="" moz-do-not-send="true">robin.mueller.m@gmail.com</a>>
wrote:<br class="">
> >><br class="">
> >> Hi,<br class="">
> >><br class="">
> >> I received a reply from STM32 about the
licensing issues. They requested more specific
information about the "vendor device restrictions"
for the HAL code.<br class="">
> >> The issue is here: <a href="https://github.com/STMicroelectronics/STM32CubeH7/issues/139" rel="noreferrer" target="_blank" class="" moz-do-not-send="true">https://github.com/STMicroelectronics/STM32CubeH7/issues/139</a><br class="">
> >> Can anyone provide more information
about this (maybe even directly in the issue) ? I can
forward it to them as well. Thanks a lot in advance!<br class="">
> >><br class="">
> >> Kind Regards<br class="">
> >> Robin<br class="">
> >><br class="">
> >> On Wed, 28 Apr 2021 at 02:45, Chris
Johns <<a href="mailto:chrisj@rtems.org" target="_blank" class="" moz-do-not-send="true">chrisj@rtems.org</a>>
wrote:<br class="">
> >>><br class="">
> >>> On 28/4/21 2:58 am, Robin Müller
wrote:<br class="">
> >>> > Okay, I can understand that
you'd like to have one build system only. We had the<br class="">
> >>> > same issue with a former
Makefile build system and the new CMake system and<br class="">
> >>> > decided to make the former
system obsolete> because maintaining both of them
would be too much work<br class="">
> >>> For RTEMS what we use has been
selected for a range of important reasons and the<br class="">
> >>> rtems-central repo and the qual work
highlights the importance of those<br class="">
> >>> decisions. Waf is a python framework
for building software and in rtems.git our<br class="">
> >>> build system support is written in a
clearly defined portable language with<br class="">
> >>> power helper libraries. We can run
code formatters on our build system, have<br class="">
> >>> unit tests and there is even source
level debuggers. We treat the build system<br class="">
> >>> like any other piece of code we
have.<br class="">
> >>><br class="">
> >>> > First thing I can do is that I
split up the patch and extract the CMake<br class="">
> >>> > specific files. Concerning a
clean solution to allow users to use CMake without<br class="">
> >>> > introducing files like
CMakeLists.txt,<br class="">
> >>> > I am not sure right now.
Extracting the information required by CMake would<br class="">
> >>> > again require scripts to export
source files and include paths.<br class="">
> >>> > The simplest solution would
still be a CMakeLists.txt file in the root here<br class="">
> >>> > which simply sets source files
and include paths in the parent scope.<br class="">
> >>> > which would again be another
form of maintenance burden because it still needs<br class="">
> >>> > to figure out which port
sources to add etc.<br class="">
> >>><br class="">
> >>> What about scons, meson, or a plain
Makefile for those who just want to use<br class="">
> >>> make, then there is GNU make and BSD
make, the list is large? Do we open the<br class="">
> >>> repo up so all build systems are
welcome? I think we would have to so we are not<br class="">
> >>> picking favourites.<br class="">
> >>><br class="">
> >>> Who tests these build system files
when the package is released? As the person<br class="">
> >>> who releases RTEMS I do not have the
time or capability to do this.<br class="">
> >>><br class="">
> >>> > The rtems-cmake support is able
to live without CMakeLists.txt files in RTEMS<br class="">
> >>> > because the BSP is already
compiled at that point. Doing something similar<br class="">
> >>> > would require a similar process
like done in the BSP where rtems-lwip is<br class="">
> >>> > compiled as a static library
for a specific BSP,<br class="">
> >>> > installed somewhere and then an
application can link against it while also<br class="">
> >>> > including the headers.<br class="">
> >>><br class="">
> >>> I welcome the idea of rtems-cmake to
grow a community of those using cmake to<br class="">
> >>> build RTEMS applications. It is
great to see this happening.<br class="">
> >>><br class="">
> >>> > For the RTEMS BSP this is done
through provided PKG Config files. It just seems<br class="">
> >>> > like a lot of effort for a
comparatively small library.<br class="">
> >>> > Maybe someone has a better
idea?<br class="">
> >>><br class="">
> >>> I do not have a better solution than
PKG config. Most build systems provide<br class="">
> >>> support so it should be something
that can be accommodated.<br class="">
> >>><br class="">
> >>> > I am also not sure if users who
are used to CMake would not just do the same<br class="">
> >>> > thing I did if there are no
CMakeLists.txt files present and the<br class="">
> >>> > library/repository is simple
enough:<br class="">
> >>><br class="">
> >>> I would discourage this and maybe
not for the reasons you may be thinking of.<br class="">
> >>> The repo is new and is it is
exciting there is work happening on it but in time<br class="">
> >>> it will become stable and it will be
released with RTEMS and this puts it in the<br class="">
> >>> same configuration management basket
as the BSP (kernel) and tools. The RSB can<br class="">
> >>> build it in a controlled way with
reports and you just access it like the BSP.<br class="">
> >>><br class="">
> >>> > Add those themselves in the
project root or throughout the repository fork<br class="">
> >>> > structure. But it's your call
of course. Maybe some more (user) opinions would<br class="">
> >>> > help as well.<br class="">
> >>><br class="">
> >>> I see rtems-cmake providing that
role, thank you for it. We have learnt the hard<br class="">
> >>> way over a few decades to be mindful
when adding these things. Strong portable<br class="">
> >>> eco-system level interfaces are our
focus.<br class="">
> >>><br class="">
> >>> Chris<br class="">
</blockquote>
</div>
_______________________________________________<br class="">
devel mailing list<br class="">
<a href="mailto:devel@rtems.org" class="" moz-do-not-send="true">devel@rtems.org</a><br class="">
<a class="moz-txt-link-freetext" href="http://lists.rtems.org/mailman/listinfo/devel">http://lists.rtems.org/mailman/listinfo/devel</a></div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
</div>
</div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">devel mailing list<br class=""><a href="mailto:devel@rtems.org" class="">devel@rtems.org</a><br class="">http://lists.rtems.org/mailman/listinfo/devel</div></blockquote></div><br class="">
<br class=""></div></body></html>