public inbox for
 help / color / mirror / Atom feed
From: Frank Pagliughi <>
To: "Bernard Fouché" <>
Subject: Re: Closing devices
Date: Fri, 22 Jun 2012 14:48:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> 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.


      reply	other threads:[~2012-06-22 14:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-12 12:34 Handling RTS with an UART that doesn't directly drives the RTS pin Bernard Fouché
2012-06-12 13:12 ` Stanislav Meduna
2012-06-12 13:16 ` Nick Garnett
2012-06-12 16:56   ` Bernard Fouché
2012-06-13 10:10     ` Nick Garnett
2012-06-13 16:37       ` Bernard Fouché
2012-06-14 15:33         ` Bernard Fouché
     [not found] ` <>
2012-06-18 14:34   ` Closing devices Frank Pagliughi
2012-06-19 13:36     ` Bernard Fouché
2012-06-20 13:38       ` Frank Pagliughi
2012-06-20 15:20         ` Bernard Fouché
2012-06-21 18:20           ` Frank Pagliughi
2012-06-22  8:33             ` Bernard Fouché
2012-06-22 14:48               ` Frank Pagliughi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).