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 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] kern_tc.c: Update pps_event() for uniprocessor configurations
On 30/05/2022 09:29, Gabriel Moyano wrote:
Since pps->capgen is not used in uniprocessor configurations, there is no need
to verified if it is equal to zero
Update #2349
---
cpukit/score/src/kern_tc.c | 4
1 file changed, 4 insertions(+)
diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
index 92739d8edd..897f81511e 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -2165,7 +2165,11 @@ pps_event(struct pps_state *pps, int event)
if ((event & pps->ppsparam.mode) == 0)
return;
/* If the timecounter was wound up underneath us, bail out. */
+#if defined(RTEMS_SMP)
if (pps->capgen == 0 || pps->capgen !=
+#else
+ if (pps->capgen !=
+#endif
atomic_load_acq_int(&pps->capth->th_generation))
return;
I think this fix is incomplete. What is with:
void
pps_capture(struct pps_state *pps)
{
struct timehands *th;
KASSERT(pps != NULL, ("NULL pps pointer in pps_capture"));
th = timehands;
pps->capgen = atomic_load_acq_int(&th->th_generation);
pps->capth = th;
#ifdef FFCLOCK
pps->capffth = fftimehands;
#endif
pps->capcount = th->th_counter->tc_get_timecount(th->th_counter);
atomic_thread_fence_acq();
if (pps->capgen != th->th_generation)
pps->capgen = 0;
}
I don't know why there is this "if" in the code. I will ask on a FreeBSD
mailing list.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
AW: [PATCH] kern_tc.c: Update pps_event() for uniprocessor configurations
> On 30/05/2022 09:29, Gabriel Moyano wrote:
> > Since pps->capgen is not used in uniprocessor configurations, there is
> > no need to verified if it is equal to zero
> >
> > Update #2349
> > ---
> > cpukit/score/src/kern_tc.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
> > index 92739d8edd..897f81511e 100644
> > --- a/cpukit/score/src/kern_tc.c
> > +++ b/cpukit/score/src/kern_tc.c
> > @@ -2165,7 +2165,11 @@ pps_event(struct pps_state *pps, int event)
> > if ((event & pps->ppsparam.mode) == 0)
> > return;
> > /* If the timecounter was wound up underneath us, bail out. */
> > +#if defined(RTEMS_SMP)
> > if (pps->capgen == 0 || pps->capgen !=
> > +#else
> > + if (pps->capgen !=
> > +#endif
> > atomic_load_acq_int(&pps->capth->th_generation))
> > return;
> >
>
> I think this fix is incomplete. What is with:
>
> void
> pps_capture(struct pps_state *pps)
> {
> struct timehands *th;
>
> KASSERT(pps != NULL, ("NULL pps pointer in pps_capture"));
> th = timehands;
> pps->capgen = atomic_load_acq_int(&th->th_generation);
> pps->capth = th;
> #ifdef FFCLOCK
> pps->capffth = fftimehands;
> #endif
> pps->capcount = th->th_counter->tc_get_timecount(th->th_counter);
> atomic_thread_fence_acq();
> if (pps->capgen != th->th_generation)
> pps->capgen = 0;
> }
>
> I don't know why there is this "if" in the code. I will ask on a FreeBSD
> mailing list.
>
I think it is for the case that th_generation has changed in between saving the
th and th_counter. If this happens pps->capgen is set to 0 and later
pps_event() returns earlier. Since for uniprocessor th_generation equal to 0 is
not used, I guess we can removed this if for those configurations
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
