This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC] CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM


Hi
there are a few flash drivers which still implement the
CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM interface while the
way to handle the problem of executing from/modifying the flash 
in the same time is solved in newer drivers by putting the
sensitive functions to sections which at load time are put in RAM
by appending section attributes to their prototypes.
Still there might be cases when the functions can stay in flash -
one that I can think of is when the flash has separately erasable/programmable
regions and you're sure you'll only touch one while the code is in the other.
At least one comment in the strataflash .cdl says that:

        Rarely, it is useful to disable the request that flash driver code
        be copied to separate RAM for execution.  This option lets you do that.

So according to this a replacement of the interface with the new way using attributes
could have this small regression.

What do the maintainers think?

1)"I wish people stopped nitpicking the sources and do some real work instead of cleanups"
2)"All drivers should use the section attribute"
3)"We could have a macro which expands to the current attribute or to nothing if a driver
independent cdl option is set and all drivers turned to using this macro"
4)...


Thanks
Jani.


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]