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

[Kinsey Moore]

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).
>
>> 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