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