On Tue, May 31, 2022 at 3:13 PM Kinsey Moore <kinsey.mo...@oarcorp.com> wrote: > > On 5/12/2022 16:30, Vijay Kumar Banerjee wrote: > > On Sat, Apr 16, 2022 at 10:48 AM Pavel Pisa <ppisa4li...@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 > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel