> On 07/04/2022 10:36, Gabriel Moyano wrote:
> > ---
> >   spec/build/cpukit/cpuopts.yml    |  2 ++
> >   spec/build/cpukit/optppssync.yml | 16 ++++++++++++++++
> >   2 files changed, 18 insertions(+)
> >   create mode 100644 spec/build/cpukit/optppssync.yml
> >
> > diff --git a/spec/build/cpukit/cpuopts.yml
> > b/spec/build/cpukit/cpuopts.yml index 301d49ccea..db0e05395f 100644
> > --- a/spec/build/cpukit/cpuopts.yml
> > +++ b/spec/build/cpukit/cpuopts.yml
> > @@ -49,6 +49,8 @@ links:
> >     uid: optparavirt
> >   - role: build-dependency
> >     uid: optposix
> > +- role: build-dependency
> > +  uid: optppssync
> >   - role: build-dependency
> >     uid: optprofiling
> >   - role: build-dependency
> > diff --git a/spec/build/cpukit/optppssync.yml
> > b/spec/build/cpukit/optppssync.yml
> > new file mode 100644
> > index 0000000000..6766cf0d40
> > --- /dev/null
> > +++ b/spec/build/cpukit/optppssync.yml
> > @@ -0,0 +1,16 @@
> > +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> > +actions:
> > +- get-boolean: null
> > +- env-enable: null
> > +- define-condition: null
> > +build-type: option
> > +copyrights:
> > +- Copyright (C) 2022 German Aerospace Center (DLR)
> > +default: false
> > +default-by-variant: []
> > +description: |
> > +  Enable time synchronization using a Pulse Per Second signal
> > +enabled-by: true
> > +links: []
> > +name: PPS_SYNC
> > +type: build
> 
> If this should really be a CPU option, then it needs a proper RTEMS_* prefix. 

Do you mean that the name should be RTEMS_PPS_SYNC?

> Why do we need the option. What is the overhead if it is always enabled.

The PPS_SYNC option comes from FREEBSD. Without it, you can still use the API. 
For example a task can wait for an event calling time_pps_fetch().
But if it is not enabled, hardpps() isn't called and time_freq is not updated.

> In general, the patch set lacks test cases.

I was thinking that the next step could be to add a generic device which is 
required to use the API (a file descriptor is needed). This is something that 
wanted to ask in the mailing list first. When this device is added, also the 
test cases can be. Furthermore I wanted to split the submitted changes in order 
to make a review easier.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to