AW: AW: Dependencies of PPS API in rtems-libbsd

[Gabriel.Moyano at dlr.de]

> > >> I guess you want to enable tc_poll_pps in struct timecounter as well?
> > >
> > > I didn't plan to do that but it can be done just removing some #ifndef, right?
> >
> > Is this handler not use for the PPS support? If it is currently unused, then please let it disabled.
> 
> Ok. For now I was working with interrupts but I guess that the same can be done with polling, that's for that handler.
> 
> >
> > >
> > >> For what do you need the sleep() and wakeup() support? Is this only used by the RFC 2783 PPS-API implementation?
> > >
> > > Yes, they are required by pps_fetch() and pps_event()
> > >
> > >> If you want to keep implement this in RTEMS, then you can convert
> > >> this to use a condition variable from <sys/lock.h> or <rtems/thread.h>.
> > >
> > > Do you mean to add a condition variable, for example in struct
> > > pps_state, and to replace sleep() and wakeup() by wait and signal?
> > > It
> > is good idea if we don't want to use the first functions.
> >
> > Ok, it seems the pps_event() could be called by interrupt service
> > routines. In this case, you cannot use a mutex and condition variables.
> > You have to use a thread queue directly. Use the thread queue ISR lock
> > for mutual exclusion. Use _Thread_queue_Enqueue() to emulate sleep()
> > and
> > _Thread_queue_Flush_critical() to emulate wakeup(). Check all critical
> > sections that they can be protected by an ISR lock (no blocking calls and short).
> 
> Is this even so if pps_event() calls signal or broadcast? Because pps_fetch() is the only function that is waiting (and locking a mutex).

Do you mean something like this?

_Thread_queue_Queue_initialize(&pps->waiting_queue.Queue, NULL);

// To emulate sleep()
Thread_queue_Context queue_context;
_Thread_queue_Context_initialize(&queue_context);
_Thread_queue_Context_set_enqueue_do_nothing_extra(&queue_context);
Thread_Control *executing = _Thread_Executing;
_Thread_queue_Queue_acquire_critical(
    &pps->waiting_queue.Queue,
    &executing->Potpourri_stats,
    &queue_context.Lock_context.Lock_context
);

_Thread_queue_Context_set_thread_state(
    &queue_context,
    STATES_BLOCKED
);

_Thread_queue_Enqueue(
    &pps->waiting_queue.Queue,
    &_Thread_queue_Operations_FIFO,
    executing,
    &queue_context
);

// To emulate wakeup()
Thread_queue_Context queue_context;
_Thread_queue_Context_initialize(&queue_context);
_Thread_queue_Flush_critical(
    &pps->waiting_queue.Queue,
    &_Thread_queue_Operations_FIFO,
    _Thread_queue_Flush_default_filter,
    &queue_context
);

Unfortunately something should be missing because it doesn't work.

> 
> >
> > >
> > >> All the uses of sleep() and wakeup() need to be clearly identified and if possible avoided.
> > >
> > > May I ask, what is the reason for avoiding them?
> >
> > The sleep() and wakeup() synchronization is nice, but not suitable for real-time systems (use of hash tables).
> >
> > >
> > > What do you think about coping the functions lmax()/qmin() and the
> > > define for ENOIOCTL? For lmax()/qmin() I saw that the file
> > where are defined (libkern.h) is in libnetworking. Not sure what it is the best option here, I don't like when the things are
> duplicated.
> >
> > Since you refer to libnetworking I guess you work with RTEMS 5. Please
> > first get it working on RTEMS 6 and then we think about a back port.
> 
> Yes, I'm working with RTEMS 5 but my next step is port the changes to RTEMS 6 and then submit the patches.
> 
> >
> > >
> > > What about tvtohz(), which is defined in rtemsbsd/rtems/rtems-kernel-timesupport.c?
> 
> tvtohz() is used for converting timeval to hz, which is required by msleep(), msleep_spin() and tsleep but because they are not used,
> tvtohz() is not needed.
> 
> >
> > Maybe just copy the dependencies to kern_tc.c. Later we can try to move them to shared locations if necessary.
> 
> I did this for lmax(), qmin() and ENOIOCTL.
> 
> Thanks for your answers.