[flashrom] consts and copies
c-d.hailfinger.devel.2006 at gmx.net
Fri Nov 27 00:54:32 CET 2009
On 27.11.2009 00:30, Stefan Reinauer wrote:
> On 11/27/09 12:24 AM, Carl-Daniel Hailfinger wrote:
>> Well, with some careful changes, I think flashrom can get by with maybe
>> 2 kB of RAM or CAR. I know what to change, but I can't make 100% correct
>> RAM requirement estimates. And we'll need boatloads of const keywords.
>> Patches welcome, especially for the const stuff. The biggest writable
>> object is the flashchip array. We can make it const, but then we have to
>> copy each chip to a temporary variable during probe. Not really ideal. Hm.
> Why the copy?
> Can't we instead have a writable struct flashchip_instance and let that
> contain a pointer to the current readonly struct flashchip member?
- You'd have to split struct flashchip into const-by-nature and
variable-by-nature fields. Can do, but it needs a replacement of struct
flashchip to struct flashchip_instance and associated glue code in every
function in flashrom.
- Handling chips with varying sizes (based on some config byte) is
broken by this change.
- Since such a change will break every other unapplied patch out there,
the only chance this has in getting in is when the patch queue size is
near zero. Won't happen anytime soon if the current review rate (more
patches sent than reviewed) is any indication.
To summarize, the copy approach is the only thing that has a chance of
going in in the next few weeks unless a review wonder happens and we can
agree on dropping support for a few variable-size chips.
Plus, we have to convert all of printf(), printf_debug(),
fprintf(stderr,) to wrapper functions which can be compiled out or be
adapted to serialice. And we need a rewritten main(). Doable, but post
0.9.2 material (unless someone sends easy-to-review patches).
I don't want to discourage you, but it won't be a walk in the park.
Developer quote of the month:
"We are juggling too many chainsaws and flaming arrows and tigers."
More information about the flashrom