[PATCH v2] STM32 lwIP addition and CMake support
Robin Mueller
robin.mueller.m at gmail.com
Thu Sep 9 10:01:32 UTC 2021
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210909/c551518c/attachment-0001.html>
More information about the devel
mailing list