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

[Vijay Kumar Banerjee]

Hello everyone,

I have pushed this patch and I would like to add a note regarding that.

This patch started interesting discussions about the possible ways to
organize code from multiple sources. Pavel also raised an issue with
the directory name "uLan". Since the repository is still in a personal
area and still in the development stage, we can make rapid changes to
the repository. We will change the directory name from uLan to
something that's more suitable, but for now, I pushed the patch so
that Kinsey can continue working on other patches. There is also a
discussion on the included licenses. I believe that the approach in
that direction will also mature as we keep bringing new patches and
involve the wider community.

Thank you to everyone for providing valuable feedback.

Best regards,
Vijay

On Tue, May 31, 2022 at 8:04 PM Vijay Kumar Banerjee <vijay at rtems.org> wrote:
>
> 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
> >