[ECOS] Re: Waiting I/O operation

Alexey Shusharin mrfinch@mail.ru
Mon Jul 23 04:10:00 GMT 2007

Sergei Gavrikov wrote:
> Hello,
Hello all,
I'm not eCos kernel expert but I think we can use cyg_flag_setbits() in 
DSR level.

> As I could understand Andrew's main concern, that is, We aren't allowed
> to block in a DSR (cyg_flag_setbits() do it), and I am agree with him.

Yes, we can't block in a DSR and IMHO cyg_flag_setbits() doesn't do it.
If we compare Cyg_Flag::setbits() (in flag.cxx) and 
Cyg_Condition_Variable::sygnal() (in mutex.cxx) we will see that there 
are no fundamental differences. So, if we can call sygnal() in a DSR we 
are able to call setbits() too.

> I looked at the common hal's drv_api.c against the kernel's flag.cxx. As
> I could see the cyg_drv_cond_*() calls are almost the atomic funcs. I
> wouldn't say same thing about the kernel's Cyg_Flag::setbits().

drv_api.c is the implementation of driver API in configuration without 
kernel. If we use a kernel, directives in dri_api.h select kapi.c 
implementation (kernel C API). And we use code from mutex.cxx and other 
kernel code eventually.

> More that, I liked cyg_drv_cond_wait(), because that is just it
> while (cond->wait == 1) { call_dsrs (); }
> So, my application can be a kernel-less application too. I think the
> table from Chapter 13 is a good guide-line: a what allowed us to run
> from DSR:
> http://ecos.sourceware.org/docs-latest/ref/devapi-synchronization-levels.html

Yes, if you use functions from drv_api.h only, your application can be a 
kernel-less. And this is the reason why you didn't find using of flags 
in drivers. It's not recommended because the flag is not included in 
driver API.

But I would like to use flags in the application, and I know that kernel 
exist. So IMHO I can call cyg_flag_setbits() in a function which is 
called from a DSR.

Best regards
Alexey Shusharin

Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

More information about the Ecos-discuss mailing list