AW: AW: AW: AW: [PATCH] kern_tc.c: Update pps_event() for uniprocessor configurations

Gabriel.Moyano at dlr.de Gabriel.Moyano at dlr.de
Fri Jun 10 07:09:17 UTC 2022


> On 08.06.22 09:54, Gabriel.Moyano at dlr.de wrote:
> >>>>>> 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
> >>>> I asked on a FreeBSD mailing list:
> >>>>
> >>>> https://lists.freebsd.org/archives/freebsd-hackers/2022-June/001165
> >>>> .h
> >>>> tml
> >>>>
> >>> Thanks for asking.
> >>> I'll prepare and send a new patch removing the "if" for uniprocessor configurations just in case.
> >> Please wait with a new patch for a response from FreeBSD.
> >>
> > What is your suggestion here? Should we check the generation only once? Or should we leave the code as is and just remove the
> "if" in pps_capture() for uniprocessor configurations since th_generation equal to zero is not used?
> 
> We should first leave the code as is. I don't know when I have time to send patches to FreeBSD.
> 

I would like it to be considered to remove the parts where th_generation is checked to be equal to zero just for uniprocessor configurations.
The reason is that porting back these changes to RTEMS 5, the test sppps01 fails because th_generation starts with value zero. Not sure why in RTEMS 6 th_generation starts with one but since in uniprocessor configuration th_generation equal zero is not used, I think it makes sense to not consider that case.


More information about the devel mailing list