[PATCH rtems-lwip] lwip: Split sources into origin directories

[Vijay Kumar Banerjee]

On Tue, May 31, 2022 at 3:13 PM Kinsey Moore <kinsey.moore at oarcorp.com> wrote:
>
> On 5/12/2022 16:30, Vijay Kumar Banerjee wrote:
> > On Sat, Apr 16, 2022 at 10:48 AM Pavel Pisa <ppisa4lists at pikron.com> wrote:
> >> Hello Joel,
> >>
> >> On Saturday 16 of April 2022 17:26:02 Joel Sherrill wrote:
> >>> Ok. Any suggestions for a directory name? :)
> >> I am not in the full sync and I have lost the tracks where
> >> are all RTEMS LwIP repo copies.
> >>
> >> Do we speak about https://git.rtems.org/vijay/rtems-lwip.git ?
> >>
> > Yes
> Given that a better directory name doesn't appear to be forthcoming, is
> there anything else preventing this patch from going in as a starting
> point to further improvements?
> >
> >> If it is that way then LwIP uses practice to put integration
> >> stuff into "ports" directory so I would leave the structure
> >> under LwIP as it is
> >>
> >>    ports/os/rtems/arch/sys_arch.c
> >>
> >> Or if you want to somehow separate sources into more repos
> >> then possible but would complicate keep the drivers and targets
> >> in a sync in future.  I am losing tracks of the build tools etc...
> >> I hope that when it settles the simple instructions
> >> would be added on the integration page
> >>
> >>    https://devel.rtems.org/wiki/Packages/LWIP
> >>
> >> If you need to move ports/os/rtems/arch/sys_arch.c under some directory,
> >> then it should be something like
> >>
> >>    rtems-support/ports/os/rtems/arch/sys_arch.c
> >>
> > This would be a good idea. We can put all RTEMS-related ports into a
> > separate directory. If there's any driver-specific port, that can also
> > be added there and waf can be taught to pick up the right one
> > according to the target.
> I'm about to start some additional work for lwIP support on ZynqMP. I'll
> see about breaking any code written specifically by RTEMS developers
> (just Vijay at this point) into a rtemslwip directory (similar to
> rtemsbsd in rtems-libbsd).

I will push this into the repository so that we can keep working on it
incrementally.

Thank you.
> >
> >> if the code can be used over all RTEMS targets. Which should be
> >> a goal anyway and I have initiated it such way years ago.
> >> But I am not sure why to not let code in the actual
> >> lwip/ports/drivers together as well. I see that
> >> in devel branch is the most of our TMS570 code wiped
> >> out... hmm.. why. There is
> >>
> >>   lwip/ports/drivers/bbb
> >>
> >> this location seems to me as OK.
> >> In the suggested changes is
> >>
> >> {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/phy_dp83848h.c
> >>
> >> I agree with move of all TMS570 specific code under
> >>
> >>    <whatever start>/ports/driver/tms570_emac
> >>
> > I agree with this approach, as it allows adding sources with
> > problematic license (like STM) into its own directory and a warning
> > can be added to waf while building those targets.
> >
> >> Again if all these shuffles are done only for some license changes
> >> I would prefer to be noticed and I think that I would not be blocked
> >> by any of my former studnets nor the faculty to relicense code.
> >> I would inform the faculty (where I am only left from former group,
> >> where I have lead part of this development, part was at my company)
> >> as well as students.
> >>
> >> I would prefer if real developer names who invested time into work
> >> are included at least as Authors in the files but the copyright can
> >> be moved to RTEMS foundation or whatever.
> >>
> >> But as I have said I have lost track and hope that stuff will survive
> >> in some form till the time when I have some free time or studnet
> >> to work on the project as his/her theses, GSoC etc...
> >> I have used the code with external OMK make, I agree that this
> >> is not right way forward but I wait for outcome of these who
> >> have more experience with RSB and related tools and propose
> >> integration.
>
> As long as the code is licensed appropriately for inclusion in this
> project, I see no reason to relicense it under most conditions.
>
>
> Kinsey
>