Re: Closing devices

[Frank Pagliughi <fpagliughi@mindspring.com>]

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