Re: [ECOS] Devio function context?

[Nick Garnett <nickg at cygnus dot co dot uk>]

Grant Edwards <grante@visi.com> writes:

> On Wed, Mar 08, 2000 at 10:27:19AM +0000, Nick Garnett wrote:
> 
> > > > Are the functions in the DEVIO_TABLE
> > > > (read/write/get|set_config) running in the context of the
> > > > calling thread?
> > > > 
> > > > For example, can they call cyg_mutex_lock()/cyg_mutex_unlock(),
> > > > cyg_thread_delay(), etc.?
> > > 
> > > Absolutely.
> > 
> > ...but you should really use the cyg_drv_... versions of these
> > functions so that the driver is portable to non-kernel configurations.
> 
> OK, but...
> 
> 1) I couldn't find any cyg_drv_delay type of function.

There isn't. In general we decided that having device drivers
implement timeouts or delays by using kernel facilities was a bad
idea. It puts too many dependencies on the kernel into the device
drivers. We expected timeouts to be implemented at higher levels and
make use of a thread level cancel to get it out of the driver (I am
not sure whether this works at present, but is on the cards as part of
the work to provide better POSIX compatibility).

Of course if you need to use delays for internal timing purposes then
this will not work. Our expectation was that such devices would either
have their own timer facilities, or a separate hardware timer would be
allocated and controlled from the driver directly. For now, if you
need to do this then by all means use cyg_thread_delay(), I'll put the
need for this onto my TODO list and think about the best way to handle
it for some future release.

> 
> 2) Based on the HTML documentation, it's not apparent that
>    cyg_drv_mutex_[un]lock() can be called from a thread.
>    Looking at the include file, I see that they're defined to
>    be cyg_mutex[un]lock, so they obviously can. My interpration
>    of the table below was that only things with 3 X's could be
>    called from a thread.
>
> <http://sourceware.cygnus.com/ecos/docs-latest/ref/ecos-ref/synchronization-levels.html>
>

Wow! I hadn't realized that this table had got so mangled, this is
what I originally passed over to the docs people:


                                            Callable from:
Function                       ISR             DSR           Thread
----------------------------------------------------------------------

cyg_drv_isr_lock                                X               X
cyg_drv_isr_unlock                              X               X
cyg_drv_dsr_lock                                                X
cyg_drv_dsr_unlock                                              X
cyg_drv_mutex_init                                              X
cyg_drv_mutex_destroy                                           X
cyg_drv_mutex_lock                                              X
cyg_drv_mutex_trylock                                           X
cyg_drv_mutex_unlock                                            X
cyg_drv_mutex_release                                           X
cyg_drv_cond_init                                               X
cyg_drv_cond_destroy                                            X
cyg_drv_cond_wait                                               X
cyg_drv_cond_signal                             X               X
cyg_drv_cond_broadcast                          X               X
cyg_drv_interrupt_create                                        X
cyg_drv_interrupt_delete                                        X
cyg_drv_interrupt_attach        X               X               X
cyg_drv_interrupt_detach        X               X               X
cyg_drv_interrupt_mask          X               X               X
cyg_drv_interrupt_unmask        X               X               X
cyg_drv_interrupt_acknowledge   X               X               X
cyg_drv_interrupt_configure     X               X               X
cyg_drv_interrupt_level         X               X               X


So all functions are callable from thread context, with reduced
functionality at DSR and ISR levels.

I'll make sure this gets fixed in the next release.

-- 
Nick Garnett
Cygnus Solutions, a Red Hat Company
Cambridge, UK