Auf 19.01.2011 07:11, Stefan Reinauer schrieb:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [110118 21:29]:
Constify flashchips array.
This moves 99.5% of the .data section to .rodata (which ends up in .text).
Disadvantages: We have one additional memcpy with sizeof(struct flashchip) per executed probe. This is purely startup cost and won't have any impact on operation after probing.
Nice!
Thanks.
You could have a "struct flash_instance" which is passed around and contains all the instance specific information of a flash chip plus a pointer to the struct flashchip element. This way you would cleanly separate the "database" from the flash chips found in the system (and could increase the number of flashes to 16 instead of 3). I know it requires an s,flashchip,flashchip_instance, across most of the code and some additional changes, but the readability might be worth the effort.
Given that almost all the code works with the instance data, it may be better to use struct flashchip for the instance data and struct flashchip_rodata (or flashchip_def) for the table. If flashchip_rodata is an anonymous struct within flashchip, we have easy copying and can keep all currently untouched code as is. As a nice side effect, the flashrom .text size would shrink by a few percent.
My longterm plans call for programmer info (at least a pointer) in struct flashchip so that we can handle multiple flashchips on sister buses easier (e.g. software-switched "Dual BIOS" solutions) because flashchip contains e.g. a enable_this_chip function pointer.
What do you think?
Regards, Carl-Daniel