Re: Closing devices

["Bernard Fouché" <bernard.fouche@kuantic.com>]

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

    Bernard