> On 17 Jun 2019, at 17:48, Kevin O'Connor wrote:
>
> On Mon, Jun 17, 2019 at 10:36:54AM +0300, Sam Eiderman wrote:
>> So overall, WDYT?
>> Keep it extendible for a low price of ABI + “bootdevices” name.
>> Or go strict and rename to “bios-geometries”?
>
> If we add another qemu to firmware
On Mon, Jun 17, 2019 at 10:36:54AM +0300, Sam Eiderman wrote:
> So overall, WDYT?
> Keep it extendible for a low price of ABI + “bootdevices” name.
> Or go strict and rename to “bios-geometries”?
If we add another qemu to firmware interface I think the interface
should be documented. I also
Ok,
I’ll resubmit this patch series in v3, as well as v2 for SeaBIOS soon enough.
* Change “bootdevices” to “bios-geometry”, and remove the struct size
* Add cpu_to_le32 fix as Laszlo suggested or big endian hosts
* Fix last qtest commit - automatic docker tester for some reason does not have
Hi,
> Keep it extendible for a low price of ABI + “bootdevices” name.
> Or go strict and rename to “bios-geometries”?
The name should reflect what is in there, so "bios-geometries" looks
better to me. I'd also keep it strict, unless we have at least a vague
idea what might be a useful future
> On 17 Jun 2019, at 10:20, Gerd Hoffmann wrote:
>
> Hi,
>
>> We serialize this information in a similar way to the "bootorder"
>> interface.
>> The fw_cfg entry is "bootdevices" and it serializes a struct.
>
> Why "bootdevices"? I'd suggest to use "geometry" or "lchs" instead.
True, if
Hi,
> We serialize this information in a similar way to the "bootorder"
> interface.
> The fw_cfg entry is "bootdevices" and it serializes a struct.
Why "bootdevices"? I'd suggest to use "geometry" or "lchs" instead.
> At the moment the struct holds the values of logical CHS values but it
>
Using fw_cfg, supply logical CHS values directly from QEMU to the BIOS.
Non-standard logical geometries break under QEMU.
A virtual disk which contains an operating system which depends on
logical geometries (consistent values being reported from BIOS INT13
AH=08) will most likely break under
