[PATCH v2] STM32 lwIP addition and CMake support

Thu Sep 9 20:21:09 UTC 2021

Does it matter that there is a new stable release coming from the LwIP people very soon now?

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. 

As for LwIP, could you pull the code from the LwIP repo instead of ST’s repo(???) 

My 0.02CAD,

Andrei

> On 2021-September-09, at 10:30, Shiro <rt9f.3141 at gmail.com> wrote:
> 
> Hi, Robin,
> 
> There are a number of ways to manage this, but the first thought that comes to my mind is:
> 
> * Priority #1: protect the license-integrity of the RTEMS src tree.  That means any “license contamination” must be quarantined.
> 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.
> 
> * 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…
> 
> In this way, one could remove the “foreign-license” dir tree and know the RTEMS tree is clean.
> 
> Just my $0.02.
> 
> Best regards,
> -Shiro
> 
> 
>> On Sep 9, 2021, at 3:01 AM, Robin Mueller <robin.mueller.m at gmail.com <mailto:robin.mueller.m at gmail.com>> wrote:
>> 
>> Hi Shiro,
>> 
>> 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? 
>> 
>> I thought of that option as well.
>> 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.
>> 
>> Kind Regards
>> Robin
>> On 08.09.21 21:05, Shiro wrote:
>>> Hi, Robin,
>>> 
>>> 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…).
>>> 
>>> The “patch trick” to manage license contamination has worked well for others in the past.
>>> 
>>> Cheers,
>>> -Shiro
>>> 
>>>> On Sep 8, 2021, at 11:51 AM, Robin Müller <robin.mueller.m at gmail.com <mailto:robin.mueller.m at gmail.com>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Unfortunately, there was no other reply to the request.
>>>> 
>>>> 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.
>>>> 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.
>>>> 
>>>> Kind Regards
>>>> Robin
>>>> 
>>>> On Thu, 5 Aug 2021 at 17:00, Gedare Bloom <gedare at rtems.org <mailto:gedare at rtems.org>> wrote:
>>>> STM is not going to fix their Ultimate Liberty License at this time.
>>>> https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010 <https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010>
>>>> 
>>>> So, we need to avoid using their example codes.
>>>> 
>>>> On Wed, Jun 9, 2021 at 12:16 PM Gedare Bloom <gedare at rtems.org <mailto:gedare at rtems.org>> wrote:
>>>> >
>>>> > I joined the Issue. Thanks for working on this.
>>>> >
>>>> > On Wed, Jun 9, 2021 at 11:30 AM Robin Müller <robin.mueller.m at gmail.com <mailto:robin.mueller.m at gmail.com>> wrote:
>>>> > >
>>>> > > I posted a reply but I think it did not go through. Will post it now.
>>>> > >
>>>> > > Kind Regards
>>>> > > Robin
>>>> > >
>>>> > > On Wed, 9 Jun 2021 at 18:31, Robin Müller <robin.mueller.m at gmail.com <mailto:robin.mueller.m at gmail.com>> wrote:
>>>> > >>
>>>> > >> Hi,
>>>> > >>
>>>> > >> I received a reply from STM32 about the licensing issues. They requested more specific information about the "vendor device restrictions"  for the HAL code.
>>>> > >> The issue is here: https://github.com/STMicroelectronics/STM32CubeH7/issues/139 <https://github.com/STMicroelectronics/STM32CubeH7/issues/139>
>>>> > >> 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!
>>>> > >>
>>>> > >> Kind Regards
>>>> > >> Robin
>>>> > >>
>>>> > >> On Wed, 28 Apr 2021 at 02:45, Chris Johns <chrisj at rtems.org <mailto:chrisj at rtems.org>> wrote:
>>>> > >>>
>>>> > >>> On 28/4/21 2:58 am, Robin Müller wrote:
>>>> > >>> > Okay, I can understand that you'd like to have one build system only. We had the
>>>> > >>> > same issue with a former Makefile build system and the new CMake system and
>>>> > >>> > decided to make the former system obsolete> because maintaining both of them would be too much work
>>>> > >>> For RTEMS what we use has been selected for a range of important reasons and the
>>>> > >>> rtems-central repo and the qual work highlights the importance of those
>>>> > >>> decisions. Waf is a python framework for building software and in rtems.git our
>>>> > >>> build system support is written in a clearly defined portable language with
>>>> > >>> power helper libraries. We can run code formatters on our build system, have
>>>> > >>> unit tests and there is even source level debuggers. We treat the build system
>>>> > >>> like any other piece of code we have.
>>>> > >>>
>>>> > >>> > First thing I  can do is that I split up the patch and extract the CMake
>>>> > >>> > specific files. Concerning a clean solution to allow users to use CMake without
>>>> > >>> > introducing files like CMakeLists.txt,
>>>> > >>> > I am not sure right now. Extracting the information required by CMake would
>>>> > >>> > again require scripts to export source files and include paths.
>>>> > >>> > The simplest solution would still be a CMakeLists.txt file in the root here
>>>> > >>> > which simply sets source files and include paths in the parent scope.
>>>> > >>> > which would again be another form of maintenance burden because it still needs
>>>> > >>> > to figure out which port sources to add etc.
>>>> > >>>
>>>> > >>> What about scons, meson, or a plain Makefile for those who just want to use
>>>> > >>> make, then there is GNU make and BSD make, the list is large? Do we open the
>>>> > >>> repo up so all build systems are welcome? I think we would have to so we are not
>>>> > >>> picking favourites.
>>>> > >>>
>>>> > >>> Who tests these build system files when the package is released? As the person
>>>> > >>> who releases RTEMS I do not have the time or capability to do this.
>>>> > >>>
>>>> > >>> > The rtems-cmake support is able to live without CMakeLists.txt files in RTEMS
>>>> > >>> > because the BSP is already compiled at that point. Doing something similar
>>>> > >>> > would require a similar process like done in the BSP where rtems-lwip is
>>>> > >>> > compiled as a static library for a specific BSP,
>>>> > >>> > installed somewhere and then an application can link against it while also
>>>> > >>> > including the headers.
>>>> > >>>
>>>> > >>> I welcome the idea of rtems-cmake to grow a community of those using cmake to
>>>> > >>> build RTEMS applications. It is great to see this happening.
>>>> > >>>
>>>> > >>> > For the RTEMS BSP this is done through provided PKG Config files. It just seems
>>>> > >>> > like a lot of effort for a comparatively small library.
>>>> > >>> > Maybe someone has a better idea?
>>>> > >>>
>>>> > >>> I do not have a better solution than PKG config. Most build systems provide
>>>> > >>> support so it should be something that can be accommodated.
>>>> > >>>
>>>> > >>> > I am also not sure if users who are used to CMake would not just do the same
>>>> > >>> > thing I did if there are no CMakeLists.txt files present and the
>>>> > >>> > library/repository is simple enough:
>>>> > >>>
>>>> > >>> I would discourage this and maybe not for the reasons you may be thinking of.
>>>> > >>> The repo is new and is it is exciting there is work happening on it but in time
>>>> > >>> it will become stable and it will be released with RTEMS and this puts it in the
>>>> > >>> same configuration management basket as the BSP (kernel) and tools. The RSB can
>>>> > >>> build it in a controlled way with reports and you just access it like the BSP.
>>>> > >>>
>>>> > >>> > Add those themselves in the project root or throughout the repository fork
>>>> > >>> > structure. But it's your call of course. Maybe some more (user) opinions would
>>>> > >>> > help as well.
>>>> > >>>
>>>> > >>> I see rtems-cmake providing that role, thank you for it. We have learnt the hard
>>>> > >>> way over a few decades to be mindful when adding these things. Strong portable
>>>> > >>> eco-system level interfaces are our focus.
>>>> > >>>
>>>> > >>> Chris
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel at rtems.org <mailto:devel at rtems.org>
>>>> http://lists.rtems.org/mailman/listinfo/devel <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/20210909/32547c66/attachment-0001.html>