Daniel Helgason wrote: > > It seems a bit of a pity to have to take two mutexs to perform a flash > operation. Would it be worth considering making the locking strategy a > configurable option in io/flash? Perhaps the choices could be none, > common, or per-driver.
There's probably a better way to abstract this than making it an option - it's an intrinsic property of the driver and should be set automatically. After all, we want to support multiple different drivers in a system, with completely different properties. It imagine it could be expressed some way via some variant of the CYG_FLASH_DRIVER macro. An initial thought is CYG_FLASH_DRIVER_NO_LOCK for the case with no locks so the driver is responsible for locking if any is required. Then you can also have CYG_FLASH_DRIVER_SHARED_LOCK (better name suggestions welcomed) to which you pass, along with the usual stuff, another CYG_FLASH_DRIVER instance with which you share the same mutex lock. The ability to selectively push locking into the driver would be worthwhile - it would make it feasible to support operations like erasing of entire planes. The above would make it possible I believe. But in the most common case, we don't want to increase the porting effort of individual drivers by requiring them to always do locking themselves, IMHO. So anything which requires changing existing drivers should be considered a no-no, especially since it should be after eCos 3.0. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
