On 02/16/19 12:21, Markus Armbruster wrote:
> Laszlo Ersek <ler...@redhat.com> writes:
>> On 02/15/19 17:01, Markus Armbruster wrote:
>>> Using whatever size the image has is sloppy modelling.
>>
>> Maybe so, but it's also very convenient, and also quite important, right
>> now (given the multiple firmware image sizes used in the wild).
>>
>>> A machine may come in minor variations that aren't worth their own
>>> machine type. One such variation could be a different flash chip size.
>>> Using the image size to select one from the set of fixed sizes is
>>> tolerable.
>>
>> The problem is that this requires coordination between QEMU and firmware
>> development.
>>
>> (Well, I have to agree that the present patch is *already* that kind of
>> coordination;
>
> We've always had that kind of coordination. It just happens to be less
> tight in the case of PC firmware in flash than in most other cases.
>
>> my point is that when I introduced the 4MB build for OVMF,
>> I didn't have to touch QEMU. In retrospect, I'm extremely thankful for
>> that, as the introduction of the 4MB build was difficult in itself.)
>
> You don't actually need "flash size is whatever the image size is" for
> that. "Use image size to select one from the set of fixed sizes" should
> suffice.
>
> Actually, the PC machines currently comply, just with a rather large
> set: { n * 4KiB | 1 <= n <= 2048 }.
>
> I very much doubt PC firmware sizes other than powers of two between
> 64KiB and 8MiB matter. Have you ever seen real flash chips with sizes
> like 64140KiB?
Honestly, I wouldn't know. I haven't seen any physical flash chip (as
in, directing my gaze at it). I also don't know what the usual flash
chip sizes are on physical boards (e.g. I have no clue what my laptop uses).
I think a jump from 4MB to 8MB would be too large. It gives too much of
sudden convenience to firmware developers. I do agree "7MB" looks quite
lame. I really wonder about the flash sizes used on physical UEFI boards.
Thanks,
Laszlo
