From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9178 invoked by alias); 23 Jul 2007 04:10:49 -0000 Received: (qmail 9170 invoked by uid 22791); 23 Jul 2007 04:10:48 -0000 X-Spam-Check-By: sourceware.org Received: from mx3.mail.ru (HELO mx3.mail.ru) (194.67.23.149) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 23 Jul 2007 04:10:45 +0000 Received: from [85.195.160.66] (port=21350 helo=[10.0.0.21]) by mx3.mail.ru with asmtp id 1ICpFp-0007s6-00; Mon, 23 Jul 2007 08:10:41 +0400 Message-ID: <46A428FF.7070401@mail.ru> Date: Mon, 23 Jul 2007 04:10:00 -0000 From: Alexey Shusharin User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Sergei Gavrikov CC: cetoni GmbH - Uwe Kindler , ecos-discuss@sourceware.org References: <469F24AE.9060907@cetoni.de> <469F3371.2000204@mail.ru> <1184842025.17705.16.camel@sg-ubuntu> <20070720193516.GD28161@lunn.ch> <46A207FB.1020302@web.de> <20070721151040.GA8387@ubuntu> In-Reply-To: <20070721151040.GA8387@ubuntu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Re: Waiting I/O operation X-SW-Source: 2007-07/txt/msg00170.txt.bz2 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