From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30876 invoked by alias); 21 Jun 2012 18:20:52 -0000 Received: (qmail 30863 invoked by uid 22791); 21 Jun 2012 18:20:51 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from elasmtp-spurfowl.atl.sa.earthlink.net (HELO elasmtp-spurfowl.atl.sa.earthlink.net) (209.86.89.66) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 21 Jun 2012 18:20:35 +0000 Received: from [155.212.194.168] (helo=[192.168.0.5]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1ShlzU-00055i-VI; Thu, 21 Jun 2012 14:20:25 -0400 Message-ID: <4FE365DB.6080300@mindspring.com> Date: Thu, 21 Jun 2012 18:20:00 -0000 From: Frank Pagliughi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bernard_Fouch=E9?= CC: ecos-devel@ecos.sourceware.org Subject: Re: Closing devices References: <4FD7374A.1090602@kuantic.com> <4FDF355B.2010209@mindspring.com> <4FDF3C83.6050102@mindspring.com> <4FE0804A.5050002@kuantic.com> <4FE1D221.1030804@mindspring.com> <4FE1EA34.9000409@kuantic.com> In-Reply-To: <4FE1EA34.9000409@kuantic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 4d82f965df0f6dd9e3f977c6d1ea408f0a9da525759e2654317410c160b1df7333d4ccd8403c2476bca2f000fc72cd8d350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2012-06/txt/msg00012.txt.bz2 >> >> In this context - closable devices - it seems unfortunate that the >> lookup() function has the side effect of opening the device. I can >> imagine that some code might just be trying to get the devtab entry >> for other purposes. Perhaps there needs to be another search function >> that returns the entry without triggering the lookup() function? > > The problem seems yet more general: anything can call cyg_io_lookup() > and since the API doesn't have from the beginning a function call to > report 'I don't need the devtab entry anymore', then even counting the > number of times lookup() is called won't help much: my suggestion do > move hw init code from init() to lookup() is very wrong... Well, several device drivers do postpone "final" initialization until the lookup() function. But many more don't make a distinction at all. > >> >> Does the file I/O code serialize calls to lookup? I examined a few >> device drivers the implement lookup() and don't see any explicit >> mechanism to prevent race conditions, but that could be due to the >> nature of the calls not requiring it. I suppose the drivers should >> lock the scheduler when manipulating this new reference count. > > Since when calling lookup() you mostly only get a reference to the > devtab entry, there isn't any race condition. If you look at > ser_16x5x.c, when lookup() is called, it calls serial_init() in the > upper layer, in serial.c . In serial.c, the concerned channel is > initialized only once by serial_init(), for whatever lower driver > calls it. I guess this has been done to allow calling lookup() at any > time, multiple times. Sorry. I meant the individual implementations of lookup() calls in the drivers that do use it. I didn't see any that locked the scheduler before they started fiddling with registers on the device. Though admittedly, I didn't look through too many drivers. > > Well my callback scheme seems all wrong: the more I look, the more it > seems that nothing is able to track down exactly the hw driver use > made by upper layers (packages or application code). Since the > application needs to handle many details like GPIO pin setup, then it > can also mask the interrupt ;-). So much for a layered software model > with low level stuff done only in low level code... > I just want to reiterate that I am trying to find a mechanism by which I can add the capability to write *new* drivers that can close their devices, without breaking the existing code. So all the drivers that already exist would work in the exact same way - they are fully opened after init() and the first call to lookup(), and they never close. But if you want to write new drivers that can be closed, or modify select ones that are already written than there is a mechanism to do so, even if there are some constraints on using these new devices. For example, if multiple threads are using a device and one thread calls the yet-to-be-implemented cyg_io_shutdown() funtion, obviously the device would be closed for all the threads. New applications that make use of the device "close" feature would need to be conscious of this and properly protect and share the closable objects. It's just maddening to me that when you use the File IO layer, and you call close(fd) on your device, nothing gets propogated to the driver and it still keeps chugging away, servicing interrupts, and consuming CPU time and electric power, even though the application thought that it "closed" the device. Does that make sense? Frank