On 07.11.2010 19:26, erik quanstrom wrote: >> The big problem with defining it as an array inside struct spicmd is >> that writearr has variable length. writearr is a command sent to a SPI >> chip by a SPI controller. writearr can have any length of 1-1056 bytes. >> There's also an analogous readarr in struct spi_command (not mentioned >> in the example to keep it brief) and that one can have any length >> between 0 and 16777217 (2^24+1) bytes. One variable-length array at the >> end of a struct is possible, but an array of structs with a variable >> length array in the struct won't work since you can't compute the offset >> of individual members of the outer arrray. >> > > what is the largest sequence of commands in practice? >
In practice: Right now (with incomplete support for some chips): writearr: 260 bytes readarr: 16777217 bytes In the near future (maybe 2 weeks from now): writearr: 1056 bytes readarr: 16777217 bytes The theoretical limit for readarr is unlimited, and we're already seeing prototypes of chips which would benefit from readarr size above 16 MB. The theoretical limit for writearr is around 16 MB as well, but I've not seen hardware requiring that (yet). readarr size depends on the host and the hardware and can be limited dynamically. For some hardware it is essential to maximize readarr to get reasonable speed (we're talking about a slowdown factor of 1000 for small readarr vs. large readarr). Given that flashrom also runs in resource-constrained environments (32 kB RAM), we determine readarr size at runtime based on resource constraints. However, given that the call graph which passes struct spi_command along can easily reach 5 or 6 levels (keeping each function minimal to avoid code duplication), passing a full array instead of a pointer via the stack means we have a copy overhead of sizeof(readarr)-sizeof(void*) plus sizeof(writearr)-sizeof(void*). Regards, Carl-Daniel -- http://www.hailfinger.org/
