On 10.06.22 09:09, gabriel.moy...@dlr.de wrote:
On 08.06.22 09:54,gabriel.moy...@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.
Yes, please fix this. What I meant is that we should not change the
FreeBSD code in general.
--
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
