Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
Hi Pavel, On Thu, Jun 2, 2022 at 12:09 AM Pavel Pisa wrote: > > Dear Vijay, > > On Thursday 02 of June 2022 05:56:56 Vijay Kumar Banerjee wrote: > > I have pushed this patch and I would like to add a note regarding that. > > thanks for the work and time. > No problem. I hope we can soon promote the rtems-lwip repository to the top-level. > > 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, > > please no uLAN it is RS-485 protocol. Yes it has and reuses our sysless > firware base project and uses OOMK build system which we use > for build of GNU/Linux, sysless, RTEMS, NuttX and even Windows > applications. Because I used our port of LwIP which uses OMK > build to test it in RTEMS I have named it lwip-omk and because > we use the code in our instruments firmware which use OMK build, > sysless and often uLAN protocol it ended in the repo under > uLAN project. > > https://sourceforge.net/p/ulan/lwip-omk/ci/omk-devel/tree/ > > But using this project name in the case where > OMK buid system is unwanted, there is nor RS-485 connection > and no use of other libraries and bare metal support from > that PiKRON project is so misleading, that I have to insist > to not use uLAN label... > > I suggest to have only ports directory at the rtems-lwip > toplevel. We should go through the process to relicense > all (where we are authors or where we can contact author) > to RTEMS mainline acceptable licence. If there is some problematic > driver then it stays in > > ports/driver/driver_name > > directory so it will be separated and license precisely defined > in that directory. > This is a good idea, and I totally agree with this approach. The directories can be named with the target name, and the information of the source can be included in a file there. > I still see in the driers base only our own tms570_emac. > So what is the plan for integrating others? > I realized that a few patches are in my local machine that never made it to the repository. Kinsey is working on another port. We will have at least two more ports soon. > It would be great to have there at least two working > ports because then it will be seen how to select them > on the build system level. > > Thanks for updating project documentation > > https://devel.rtems.org/wiki/Packages/LWIP > > There is another task to solve. In the OMK build, > there has been made possible to configure the most > of the LwIP options from the project top level > config.omk and config.target. It should be considered, > how buffers size, count and many other featires will > be configured in actual RSB build. Problem is that > LwIP on targets with little memory (it worked on > 256 kB TMS570LS3137) and on the other hand configuration > for some bigger systems as is Gaisler GR740 or somethink > NOEL-V based can be significantly different when > megabytes of RAM can be used. > The waf scripts can be extended in the way similar to top level rtems-littlevgl that provides a default header file with config info, which get rewritten by the script based on manual configurations. https://git.rtems.org/packages/rtems-littlevgl/ > By the way, I am presenting at > > 9th International Workshop on Analogue and Mixed-Signal > Integrated Circuits for Space Applications > https://indico.esa.int/event/388/ > Nice! > and I have met there people from TTTech > and they can have interrest to try RTEMS > even on their TTEthernet space ASIC > internal Leon 2 core. But it is memory > constrained environment so for TCP/IP non-real time > traffic they most probably cannot use BSD stack, > so LwIP + RTEMS can be the option there. > This can be a nice project. > But it is necessary to put project into some > reusable shape. Unfortunately I do not have > time to work on it some intensive way now > and I do not know RSB stuff enough. > Handling the config will be the challenge, but a plain vanilla rtems-lwip can be built using similar RSB script used for libbsd. > On the other hand, if they express real interest, > I can try, if I am able attract some students > from our universitywho can work on the project. > I invest a lot to pass knowledge for their serious > work in this area. > > By the way, we have switched our Computer Architectures > course to RISC-V in this run > > https://cw.fel.cvut.cz/wiki/courses/b35apo/en/start > > including simulator > > https://github.com/cvut/qtrvsim > > and public recording (even English, sorry Czenglish) > > https://www.youtube.com/playlist?list=PLQL6z4JeTTQnTrML7HgagbjdpCtvdyu0M Thanks for making the lecture pdfs public and uploading the videos on youtube! Best regards, Vijay > > Best wishes, > >
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
Dear Vijay, On Thursday 02 of June 2022 05:56:56 Vijay Kumar Banerjee wrote: > I have pushed this patch and I would like to add a note regarding that. thanks for the work and time. > 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, please no uLAN it is RS-485 protocol. Yes it has and reuses our sysless firware base project and uses OOMK build system which we use for build of GNU/Linux, sysless, RTEMS, NuttX and even Windows applications. Because I used our port of LwIP which uses OMK build to test it in RTEMS I have named it lwip-omk and because we use the code in our instruments firmware which use OMK build, sysless and often uLAN protocol it ended in the repo under uLAN project. https://sourceforge.net/p/ulan/lwip-omk/ci/omk-devel/tree/ But using this project name in the case where OMK buid system is unwanted, there is nor RS-485 connection and no use of other libraries and bare metal support from that PiKRON project is so misleading, that I have to insist to not use uLAN label... I suggest to have only ports directory at the rtems-lwip toplevel. We should go through the process to relicense all (where we are authors or where we can contact author) to RTEMS mainline acceptable licence. If there is some problematic driver then it stays in ports/driver/driver_name directory so it will be separated and license precisely defined in that directory. I still see in the driers base only our own tms570_emac. So what is the plan for integrating others? It would be great to have there at least two working ports because then it will be seen how to select them on the build system level. Thanks for updating project documentation https://devel.rtems.org/wiki/Packages/LWIP There is another task to solve. In the OMK build, there has been made possible to configure the most of the LwIP options from the project top level config.omk and config.target. It should be considered, how buffers size, count and many other featires will be configured in actual RSB build. Problem is that LwIP on targets with little memory (it worked on 256 kB TMS570LS3137) and on the other hand configuration for some bigger systems as is Gaisler GR740 or somethink NOEL-V based can be significantly different when megabytes of RAM can be used. By the way, I am presenting at 9th International Workshop on Analogue and Mixed-Signal Integrated Circuits for Space Applications https://indico.esa.int/event/388/ and I have met there people from TTTech and they can have interrest to try RTEMS even on their TTEthernet space ASIC internal Leon 2 core. But it is memory constrained environment so for TCP/IP non-real time traffic they most probably cannot use BSD stack, so LwIP + RTEMS can be the option there. But it is necessary to put project into some reusable shape. Unfortunately I do not have time to work on it some intensive way now and I do not know RSB stuff enough. On the other hand, if they express real interest, I can try, if I am able attract some students from our universitywho can work on the project. I invest a lot to pass knowledge for their serious work in this area. By the way, we have switched our Computer Architectures course to RISC-V in this run https://cw.fel.cvut.cz/wiki/courses/b35apo/en/start including simulator https://github.com/cvut/qtrvsim and public recording (even English, sorry Czenglish) https://www.youtube.com/playlist?list=PLQL6z4JeTTQnTrML7HgagbjdpCtvdyu0M Best wishes, Pavel Pisa == PiKRON s.r.o. Phone/Fax: +420 284684676 Kankovskeho 1235Phone: +420 234697622 182 00 Praha 8 WWW: http://www.pikron.com/ Czech Republic e-mail: pik...@pikron.com == ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
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 wrote:
>
> On Tue, May 31, 2022 at 3:13 PM Kinsey Moore wrote:
> >
> > On 5/12/2022 16:30, Vijay Kumar Banerjee wrote:
> > > On Sat, Apr 16, 2022 at 10:48 AM Pavel Pisa
> > > 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
> > >>
> > >>/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
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
On Tue, May 31, 2022 at 3:13 PM Kinsey Moore wrote:
>
> On 5/12/2022 16:30, Vijay Kumar Banerjee wrote:
> > On Sat, Apr 16, 2022 at 10:48 AM Pavel Pisa 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
> >>
> >>/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
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
On 5/12/2022 16:30, Vijay Kumar Banerjee wrote:
On Sat, Apr 16, 2022 at 10:48 AM Pavel Pisa 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
/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
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
On Sat, Apr 16, 2022 at 10:48 AM Pavel Pisa wrote:
>
> Hello Joel,
>
> On Saturday 16 of April 2022 17:26:02 Joel Sherrill wrote:
> > On Sat, Apr 16, 2022, 9:54 AM Pavel Pisa wrote:
> > > On Thursday 14 of April 2022 22:08:00 Vijay Kumar Banerjee wrote:
> > > > rename {lwip => uLan}/ports/os/lwipopts.h (100%)
> > > >
> > > > > rename {lwip => uLan}/ports/os/rtems/arch/cc.h (100%)
> > > > > rename {lwip => uLan}/ports/os/rtems/arch/perf.h (100%)
> > > > > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.c (100%)
> > > > > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.h (100%)
> >
> > 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
> 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.
> 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
>
> /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.
>
> Best wishes,
>
> Pavel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
Hello Joel,
On Saturday 16 of April 2022 17:26:02 Joel Sherrill wrote:
> On Sat, Apr 16, 2022, 9:54 AM Pavel Pisa wrote:
> > On Thursday 14 of April 2022 22:08:00 Vijay Kumar Banerjee wrote:
> > > rename {lwip => uLan}/ports/os/lwipopts.h (100%)
> > >
> > > > rename {lwip => uLan}/ports/os/rtems/arch/cc.h (100%)
> > > > rename {lwip => uLan}/ports/os/rtems/arch/perf.h (100%)
> > > > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.c (100%)
> > > > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.h (100%)
>
> 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 ?
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
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
/ports/driver/tms570_emac
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.
Best wishes,
Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
On Sat, Apr 16, 2022, 9:54 AM Pavel Pisa wrote:
> Hi Vijay and Kinsey,
>
> I monitor from distance LwIP for RTEMS progress and I am happy
> for that and when the code settles and I find a time,
> I try to test it with TMS570. But I have notices next moves
>
> On Thursday 14 of April 2022 22:08:00 Vijay Kumar Banerjee wrote:
> > rename {lwip => uLan}/ports/os/lwipopts.h (100%)
> >
> > > rename {lwip => uLan}/ports/os/rtems/arch/cc.h (100%)
> > > rename {lwip => uLan}/ports/os/rtems/arch/perf.h (100%)
> > > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.c (100%)
> > > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.h (100%)
>
> please do not use uLAN for directory name inside LwIP.
> uLAN is our RS-485 communication protocol project
> and it includes sysless (bare hardware integration layer)
> as well as others for RTEMS, NuttX, GNU/Linux.
> And LwIP is used as subproject inside our larger projects.
> Yes, project is used as base for more our project even
> unrelated to RS-485 but that is historical relict
> and should not propagate into RTEMS.
>
> But there is no reason to keep uLAN in the name.
> These parts which I have written myself or has been
> writtent by Roman Bartosinski under my company
> (PiKRON) and colleague Alvat.cz funding acan be
> relicensed under any RTEMS compatible preferred license.
> Only me and Roman needs to agree on that and I do not
> see that as a problem. So do not put there uLAN name.
> This RTEMS specific integration should stay in some
> RTEMS specific LwIP subdirectory or can be even included
> into RTEMS mainline. But please, do not add there uLAN
> name nor OMK (our makesystem abbreviation).
>
Ok. Any suggestions for a directory name? :)
--joel
> Best wishes,
>
> Pavel
> --
> Pavel Pisa
> phone: +420 603531357
> e-mail: p...@cmp.felk.cvut.cz
> Department of Control Engineering FEE CVUT
> Karlovo namesti 13, 121 35, Prague 2
> university: http://control.fel.cvut.cz/
> company:https://www.pikron.com/
> personal: http://cmp.felk.cvut.cz/~pisa
> projects: https://www.openhub.net/accounts/ppisa
> CAN related:http://canbus.pages.fel.cvut.cz/
> Open Technologies Research Education and Exchange Services
> https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
Hi Vijay and Kinsey,
I monitor from distance LwIP for RTEMS progress and I am happy
for that and when the code settles and I find a time,
I try to test it with TMS570. But I have notices next moves
On Thursday 14 of April 2022 22:08:00 Vijay Kumar Banerjee wrote:
> rename {lwip => uLan}/ports/os/lwipopts.h (100%)
>
> > rename {lwip => uLan}/ports/os/rtems/arch/cc.h (100%)
> > rename {lwip => uLan}/ports/os/rtems/arch/perf.h (100%)
> > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.c (100%)
> > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.h (100%)
please do not use uLAN for directory name inside LwIP.
uLAN is our RS-485 communication protocol project
and it includes sysless (bare hardware integration layer)
as well as others for RTEMS, NuttX, GNU/Linux.
And LwIP is used as subproject inside our larger projects.
Yes, project is used as base for more our project even
unrelated to RS-485 but that is historical relict
and should not propagate into RTEMS.
But there is no reason to keep uLAN in the name.
These parts which I have written myself or has been
writtent by Roman Bartosinski under my company
(PiKRON) and colleague Alvat.cz funding acan be
relicensed under any RTEMS compatible preferred license.
Only me and Roman needs to agree on that and I do not
see that as a problem. So do not put there uLAN name.
This RTEMS specific integration should stay in some
RTEMS specific LwIP subdirectory or can be even included
into RTEMS mainline. But please, do not add there uLAN
name nor OMK (our makesystem abbreviation).
Best wishes,
Pavel
--
Pavel Pisa
phone: +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
company:https://www.pikron.com/
personal: http://cmp.felk.cvut.cz/~pisa
projects: https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
I'm ok with it. Just wondering what's left on the list before moving this
to a community shared area? :)
--joel
On Thu, Apr 14, 2022 at 3:08 PM Vijay Kumar Banerjee
wrote:
> Hi Kinsey,
>
> Thank you for sorting this out. I will merge it on Monday if no one
> objects.
>
> Best regards,
> Vijay
>
> On Thu, Apr 14, 2022 at 11:33 AM Kinsey Moore
> wrote:
> >
> > Moving forward, each origin directory should have its own top-level
> > COPYING.origin file to describe its license as well as a ORIGIN.origin
> > file to describe where the code is sourced from.
> > ---
> > COPYING.lwip | 25 ++
> > COPYING.uLan | 33 +++
> > ORIGIN.lwip | 2 ++
> > ORIGIN.uLan | 2 ++
> > README| 14
> > lwip.py | 10 +++---
> > .../ports/driver/tms570_emac}/eth_lwip.c | 0
> > .../ports/driver/tms570_emac}/eth_lwip.h | 0
> > .../driver/tms570_emac}/eth_lwip_default.h| 0
> > .../ports/driver/tms570_emac}/phy_dp83848h.c | 0
> > .../ports/driver/tms570_emac}/phy_dp83848h.h | 0
> > .../ports/driver/tms570_emac}/ti_drv_emac.h | 0
> > .../ports/driver/tms570_emac}/ti_drv_mdio.h | 0
> > .../ports/driver/tms570_emac}/tms570_emac.h | 0
> > .../ports/driver/tms570_emac}/tms570_netif.c | 0
> > .../ports/driver/tms570_emac}/tms570_netif.h | 0
> > {lwip => uLan}/ports/os/lwipopts.h| 0
> > {lwip => uLan}/ports/os/rtems/arch/cc.h | 0
> > {lwip => uLan}/ports/os/rtems/arch/perf.h | 0
> > {lwip => uLan}/ports/os/rtems/arch/sys_arch.c | 0
> > {lwip => uLan}/ports/os/rtems/arch/sys_arch.h | 0
> > 21 files changed, 81 insertions(+), 5 deletions(-)
> > create mode 100644 COPYING.lwip
> > create mode 100644 COPYING.uLan
> > create mode 100644 ORIGIN.lwip
> > create mode 100644 ORIGIN.uLan
> > create mode 100644 README
> > rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/eth_lwip.c
> (100%)
> > rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/eth_lwip.h
> (100%)
> > rename {lwip/ports/drivers =>
> uLan/ports/driver/tms570_emac}/eth_lwip_default.h (100%)
> > rename {lwip/ports/drivers =>
> uLan/ports/driver/tms570_emac}/phy_dp83848h.c (100%)
> > rename {lwip/ports/drivers =>
> uLan/ports/driver/tms570_emac}/phy_dp83848h.h (100%)
> > rename {lwip/ports/drivers =>
> uLan/ports/driver/tms570_emac}/ti_drv_emac.h (100%)
> > rename {lwip/ports/drivers =>
> uLan/ports/driver/tms570_emac}/ti_drv_mdio.h (100%)
> > rename {lwip/ports/drivers =>
> uLan/ports/driver/tms570_emac}/tms570_emac.h (100%)
> > rename {lwip/ports/drivers =>
> uLan/ports/driver/tms570_emac}/tms570_netif.c (100%)
> > rename {lwip/ports/drivers =>
> uLan/ports/driver/tms570_emac}/tms570_netif.h (100%)
> > rename {lwip => uLan}/ports/os/lwipopts.h (100%)
> > rename {lwip => uLan}/ports/os/rtems/arch/cc.h (100%)
> > rename {lwip => uLan}/ports/os/rtems/arch/perf.h (100%)
> > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.c (100%)
> > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.h (100%)
> >
> > diff --git a/COPYING.lwip b/COPYING.lwip
> > new file mode 100644
> > index 000..90465f5
> > --- /dev/null
> > +++ b/COPYING.lwip
> > @@ -0,0 +1,25 @@
> > +Copyright (c) 2001, 2002 Swedish Institute of Computer Science.
> > +All rights reserved.
> > +
> > +Redistribution and use in source and binary forms, with or without
> modification,
> > +are permitted provided that the following conditions are met:
> > +
> > +1. Redistributions of source code must retain the above copyright
> notice,
> > + this list of conditions and the following disclaimer.
> > +2. Redistributions in binary form must reproduce the above copyright
> notice,
> > + this list of conditions and the following disclaimer in the
> documentation
> > + and/or other materials provided with the distribution.
> > +3. The name of the author may not be used to endorse or promote products
> > + derived from this software without specific prior written permission.
> > +
> > +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
> IMPLIED
> > +WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> > +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
> NO EVENT
> > +SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> SPECIAL,
> > +EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
> PROCUREMENT
> > +OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> > +INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> > +CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> ARISING
> > +IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY
> > +OF SUCH DAMAGE.
> > +
> > diff --git a/COPYING.uLan
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
Hi Kinsey,
Thank you for sorting this out. I will merge it on Monday if no one objects.
Best regards,
Vijay
On Thu, Apr 14, 2022 at 11:33 AM Kinsey Moore wrote:
>
> Moving forward, each origin directory should have its own top-level
> COPYING.origin file to describe its license as well as a ORIGIN.origin
> file to describe where the code is sourced from.
> ---
> COPYING.lwip | 25 ++
> COPYING.uLan | 33 +++
> ORIGIN.lwip | 2 ++
> ORIGIN.uLan | 2 ++
> README| 14
> lwip.py | 10 +++---
> .../ports/driver/tms570_emac}/eth_lwip.c | 0
> .../ports/driver/tms570_emac}/eth_lwip.h | 0
> .../driver/tms570_emac}/eth_lwip_default.h| 0
> .../ports/driver/tms570_emac}/phy_dp83848h.c | 0
> .../ports/driver/tms570_emac}/phy_dp83848h.h | 0
> .../ports/driver/tms570_emac}/ti_drv_emac.h | 0
> .../ports/driver/tms570_emac}/ti_drv_mdio.h | 0
> .../ports/driver/tms570_emac}/tms570_emac.h | 0
> .../ports/driver/tms570_emac}/tms570_netif.c | 0
> .../ports/driver/tms570_emac}/tms570_netif.h | 0
> {lwip => uLan}/ports/os/lwipopts.h| 0
> {lwip => uLan}/ports/os/rtems/arch/cc.h | 0
> {lwip => uLan}/ports/os/rtems/arch/perf.h | 0
> {lwip => uLan}/ports/os/rtems/arch/sys_arch.c | 0
> {lwip => uLan}/ports/os/rtems/arch/sys_arch.h | 0
> 21 files changed, 81 insertions(+), 5 deletions(-)
> create mode 100644 COPYING.lwip
> create mode 100644 COPYING.uLan
> create mode 100644 ORIGIN.lwip
> create mode 100644 ORIGIN.uLan
> create mode 100644 README
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/eth_lwip.c
> (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/eth_lwip.h
> (100%)
> rename {lwip/ports/drivers =>
> uLan/ports/driver/tms570_emac}/eth_lwip_default.h (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/phy_dp83848h.c
> (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/phy_dp83848h.h
> (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/ti_drv_emac.h
> (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/ti_drv_mdio.h
> (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/tms570_emac.h
> (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/tms570_netif.c
> (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/tms570_netif.h
> (100%)
> rename {lwip => uLan}/ports/os/lwipopts.h (100%)
> rename {lwip => uLan}/ports/os/rtems/arch/cc.h (100%)
> rename {lwip => uLan}/ports/os/rtems/arch/perf.h (100%)
> rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.c (100%)
> rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.h (100%)
>
> diff --git a/COPYING.lwip b/COPYING.lwip
> new file mode 100644
> index 000..90465f5
> --- /dev/null
> +++ b/COPYING.lwip
> @@ -0,0 +1,25 @@
> +Copyright (c) 2001, 2002 Swedish Institute of Computer Science.
> +All rights reserved.
> +
> +Redistribution and use in source and binary forms, with or without
> modification,
> +are permitted provided that the following conditions are met:
> +
> +1. Redistributions of source code must retain the above copyright notice,
> + this list of conditions and the following disclaimer.
> +2. Redistributions in binary form must reproduce the above copyright notice,
> + this list of conditions and the following disclaimer in the documentation
> + and/or other materials provided with the distribution.
> +3. The name of the author may not be used to endorse or promote products
> + derived from this software without specific prior written permission.
> +
> +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
> +WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
> EVENT
> +SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
> +EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
> PROCUREMENT
> +OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> +INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> +CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> ARISING
> +IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY
> +OF SUCH DAMAGE.
> +
> diff --git a/COPYING.uLan b/COPYING.uLan
> new file mode 100644
> index 000..e23898b
> --- /dev/null
> +++ b/COPYING.uLan
> @@ -0,0 +1,33 @@
> +/*
> + * Copyright (c) 2001, 2002 Swedish Institute of Computer Science.
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> modification,
> + * are permitted provided
[PATCH rtems-lwip] lwip: Split sources into origin directories
Moving forward, each origin directory should have its own top-level
COPYING.origin file to describe its license as well as a ORIGIN.origin
file to describe where the code is sourced from.
---
COPYING.lwip | 25 ++
COPYING.uLan | 33 +++
ORIGIN.lwip | 2 ++
ORIGIN.uLan | 2 ++
README| 14
lwip.py | 10 +++---
.../ports/driver/tms570_emac}/eth_lwip.c | 0
.../ports/driver/tms570_emac}/eth_lwip.h | 0
.../driver/tms570_emac}/eth_lwip_default.h| 0
.../ports/driver/tms570_emac}/phy_dp83848h.c | 0
.../ports/driver/tms570_emac}/phy_dp83848h.h | 0
.../ports/driver/tms570_emac}/ti_drv_emac.h | 0
.../ports/driver/tms570_emac}/ti_drv_mdio.h | 0
.../ports/driver/tms570_emac}/tms570_emac.h | 0
.../ports/driver/tms570_emac}/tms570_netif.c | 0
.../ports/driver/tms570_emac}/tms570_netif.h | 0
{lwip => uLan}/ports/os/lwipopts.h| 0
{lwip => uLan}/ports/os/rtems/arch/cc.h | 0
{lwip => uLan}/ports/os/rtems/arch/perf.h | 0
{lwip => uLan}/ports/os/rtems/arch/sys_arch.c | 0
{lwip => uLan}/ports/os/rtems/arch/sys_arch.h | 0
21 files changed, 81 insertions(+), 5 deletions(-)
create mode 100644 COPYING.lwip
create mode 100644 COPYING.uLan
create mode 100644 ORIGIN.lwip
create mode 100644 ORIGIN.uLan
create mode 100644 README
rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/eth_lwip.c (100%)
rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/eth_lwip.h (100%)
rename {lwip/ports/drivers =>
uLan/ports/driver/tms570_emac}/eth_lwip_default.h (100%)
rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/phy_dp83848h.c
(100%)
rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/phy_dp83848h.h
(100%)
rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/ti_drv_emac.h
(100%)
rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/ti_drv_mdio.h
(100%)
rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/tms570_emac.h
(100%)
rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/tms570_netif.c
(100%)
rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/tms570_netif.h
(100%)
rename {lwip => uLan}/ports/os/lwipopts.h (100%)
rename {lwip => uLan}/ports/os/rtems/arch/cc.h (100%)
rename {lwip => uLan}/ports/os/rtems/arch/perf.h (100%)
rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.c (100%)
rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.h (100%)
diff --git a/COPYING.lwip b/COPYING.lwip
new file mode 100644
index 000..90465f5
--- /dev/null
+++ b/COPYING.lwip
@@ -0,0 +1,25 @@
+Copyright (c) 2001, 2002 Swedish Institute of Computer Science.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
modification,
+are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice,
+ this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright notice,
+ this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+3. The name of the author may not be used to endorse or promote products
+ derived from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
+WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT
+SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
+OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
+IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
+OF SUCH DAMAGE.
+
diff --git a/COPYING.uLan b/COPYING.uLan
new file mode 100644
index 000..e23898b
--- /dev/null
+++ b/COPYING.uLan
@@ -0,0 +1,33 @@
+/*
+ * Copyright (c) 2001, 2002 Swedish Institute of Computer Science.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
modification,
+ * are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice,
+ *this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright notice,
+ *this list of conditions and the following disclaimer in the documentation
+ *and/or other materials provided
