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