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

Le 21/06/2012 20:20, Frank Pagliughi a écrit :
>> 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.

It seems the easiest solution is too process specific config keys: 
serial.c will forward downward the config keys it does not understand 
and there is no change in CYG_IO, SERIAL, or whatever upper package. If 
you look at config_keys.h, there are already keys to enable/disable a 
CAN channel. IMHO what we want is adding similar keys to the serial 
driver system.

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

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.

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

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 ;-)

Another possible reason could be that more than 10 years ago eCos was 
not targeted to be used on systems with great power constraints since it 
was assumed the MCU was a 32 bits one and at that time 32 bits MCU were 
consuming much more power than nowadays. MCU had less embedded 
peripherals. Humanity was paying the barrel $20.

Today with cores like the Cortex-M series you can reach power 
consumption very close to a 8/16 bits system while and you have 32 bits 
luxury allowing you to move on from no OS or from a feature poor OS to 
something like eCos. In some way we rant bout having not enough caviar 
in the free lunch :-)

What we miss is some document explaining the design choices (beside the 
source code).


  reply	other threads:[~2012-06-22  8:33 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é [this message]
2012-06-22 14:48               ` Frank Pagliughi

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