From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6645 invoked by alias); 22 Jun 2012 14:48:56 -0000 Received: (qmail 6634 invoked by uid 22791); 22 Jun 2012 14:48:55 -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-kukur.atl.sa.earthlink.net (HELO elasmtp-kukur.atl.sa.earthlink.net) (209.86.89.65) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 22 Jun 2012 14:48:42 +0000 Received: from [71.241.136.125] (helo=[192.168.0.5]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Si5AA-0008UL-2P; Fri, 22 Jun 2012 10:48:42 -0400 Message-ID: <4FE485C9.1020202@mindspring.com> Date: Fri, 22 Jun 2012 14:48:00 -0000 From: Frank Pagliughi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b2 Thunderbird/3.1.16 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> <4FE365DB.6080300@mindspring.com> <4FE42DDF.8020706@kuantic.com> In-Reply-To: <4FE42DDF.8020706@kuantic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 4d82f965df0f6dd9e3f977c6d1ea408f0a9da525759e2654132be914947e2e5e279aa22d7f38b354bd6355a4fd6b880e350badd9bab72f9c350badd9bab72f9c 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/msg00014.txt.bz2 > > Using new keys, you make your own power_open() / power_close() > functions (or whatever name). They don't call close(), they use > instead cyg_io_set_config() to send the keys to the driver: this keeps > the whole package /driver organization untouched and this is a very > slight modification that may even be accepted in the eCos repo (I was > able to have new CAN keys accepted). While you are at it, what about > adding a config key to start/stop transmitting the 'break' serial > character ;-) . > > So your new driver processes these new keys, and if ever someone tries > to use the keys on a driver not supporting them, cyg_io_set_config() > will report an error and the developper knows some work is needed at > low level to add the feature on the concerned driver. I like the idea of some new, consistent keys for putting devices into a low power state(s) - like devices that can power down until something interesting happens. But to the application they are still "open". I still think that having a close/shutdown is appropriate for cases where you don't want anything from the device for some amount of time. > >> I guess part of the initial goals for eCos were to have a >> functionally rich system without being necessarily tied to the Posix >> world, while allowing easy porting of application coming from a Posix >> like system. Otherwise it would have been called eCosnix ;-) Yes, agreed. But things have certainly changed. The Linux raid on the embedded space has been great and yet somewhat devastating. The most popular open-source RTOS a few years from now will likely be something that is very compatible with Linux. My current eCos project shared about 70% of it's code with an ARM9 Linux application. So I'm looking for a solution that propagates through all of the eCos API's. This may be a personal bias. I don't tend to program eCos with full POSIX support, but I almost always use the FileIO package. It keeps the code much, much more portable. Of course, another option is to create an entirely new I/O package that can replace (or sit side-by-side) with the existing one. Then let the new package provide all the added functionality for removable and dynamic devices. But I'm not up for that at the moment! Well, I've already implemented the basic "shutdown" framework (in about an hour), and it is not very intrusive, nor very long. I will do some testing, and then upload it for comment some time next week. Frank