[ECOS] Re: Waiting I/O operation

[Alexey Shusharin]

Sergei Gavrikov wrote:
> В Пнд, 23/07/2007 в 11:05 +0700, Alexey Shusharin пишет:
>> 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.
> 
> Hello,
> 
> The DSR is a kernel driven stuff. As I understood before... The eCos
> scheduler manages the deffered service routings.

Yes, if kernel is enabled. But if not, DSRs are calling from 
call_dsrs(), which is calling from cyg_drv_cond_wait() (in drv_api.c) 
and maybe from other kernel-less configuration functions.

I think you was right in first time. ;-)

Regards
Alexey

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