This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: Closing devices
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