> > >> 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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
