From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11674 invoked by alias); 21 Jul 2007 15:11:50 -0000 Received: (qmail 11665 invoked by uid 22791); 21 Jul 2007 15:11:49 -0000 X-Spam-Check-By: sourceware.org Received: from stelecom.gomel.by (HELO stelecom.gomel.by) (82.209.213.61) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 21 Jul 2007 15:11:47 +0000 Received: from localhost (localhost [127.0.0.1]) by stelecom.gomel.by (Postfix) with ESMTP id 08E54B001061; Sat, 21 Jul 2007 18:11:45 +0300 (EEST) Received: from stelecom.gomel.by ([127.0.0.1]) by localhost (stelecom.gomel.by [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25981-14; Sat, 21 Jul 2007 18:11:43 +0300 (EEST) Received: from localhost (unknown [82.209.236.168]) by stelecom.gomel.by (Postfix) with ESMTP id 81B26B00106A; Sat, 21 Jul 2007 18:11:42 +0300 (EEST) Date: Sat, 21 Jul 2007 15:11:00 -0000 From: Sergei Gavrikov To: Uwe Kindler Cc: Alexey Shusharin , cetoni GmbH - Uwe Kindler , ecos-discuss@sourceware.org Message-ID: <20070721151040.GA8387@ubuntu> References: <469F24AE.9060907@cetoni.de> <469F3371.2000204@mail.ru> <1184842025.17705.16.camel@sg-ubuntu> <20070720193516.GD28161@lunn.ch> <46A207FB.1020302@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A207FB.1020302@web.de> User-Agent: Mutt/1.5.13 (2006-08-11) 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/msg00166.txt.bz2 On Sat, Jul 21, 2007 at 03:19:55PM +0200, Uwe Kindler wrote: > This is what the documentation says about flags and DSRs: > > http://ecos.sourceware.org/docs-latest/ref/kernel-flags.html > > So it seems to be possible to use cyg_flag_setbits() from DSRs. > Andrew Lunn schrieb: > >>But, one my today DSR uses the cyg_flag_setbits() notifier and that > >>works as I could expect. I found that is more simple, because that > >>doesn't need itself in a mutex. I wonder about the right hacking from > >>the eCos experts. > > > >You are not allowed to block in a DSR. So look through the > >cyg_flag_setbits() code and see if it calls any functions to block > >itself. > > > > Andrew Hello, 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. 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(). 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 So, I did believe in that two crosses more after Andrew's suggest to U.T.S.L :-) I did believe in those crosses even more after a comparation find $ECOS_REPOSITORY/{io,devs} | xargs grep cyg_drv_cond_ against find $ECOS_REPOSITORY/{io,devs} | xargs grep cyg_flag_ We all did talk about the DSR's possibilities, didn't all? IMHO, that is in the most an eCos driver related thing. Sergei -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss