Re: [Qemu-devel] [qemu-s390x] [PATCH v1 for-2.13 3/4] pc-bios/s390-ccw/net: Add support for pxelinux-style config files

[Thomas Huth]

On 20.04.2018 08:53, Viktor VM Mihajlovski wrote:
> On 19.04.2018 18:55, Thomas Huth wrote:
>> On 19.04.2018 14:40, Viktor VM Mihajlovski wrote:
[...]
>>>>> That's interesting because treating the bootfile as pxe-ish config is
>>>>> what DPM does. Which means that with this change the processor
>>>>> architecture type 0x1f (Basic) will turn into a superset of 0x20
>>>>> (Extended).
>>>>
>>>> Is there any reference available what "basic" and "extended" exactly
>>>> mean? I just know that there are these two values registered by you at
>>>> the IANA:
>>>>
>>>> https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#processor-architecture
>>>>
>>>> ... but I haven't seen a description of the differences of these two
>>>> values yet.
>>>>
>>> Yep, the IANA stuff is pretty terse for all architectures. In a
>>> nutshell: 0x1f is standard DHCP-based boot (bootfile is a single
>>> executable binary) and 0x20 serves a pxe-style config file instead.
>>
>> Can 0x20 also still handle binary files, or only pxe-style config files?
>>
> Unfortunately, DPM has no support for binaries which was the reason we
> ended up with two different identifiers

Ok, so switching to 0x20 is not an option for us here.

>>> In fact, "processor architecture identifier" is a misnomer, as it
>>> describes a pair of processor architecture and firmware.
>>
>> Yeah, I know ... it's even worse nowadays, it's processor + firmware +
>> TCP/IP protocol (HTTP vs. TFTP) ... we should have properly untangled
>> that when doing RFC 5970, but it was already hard enough to get that
>> accepted in the current shape, so we missed to clean up the mess from
>> RFC 4578 / PXE :-(
>>
>>> Since the QEMU firmware has two significant extensions now (insfile and
>>> direct config file loading), it might be worthwhile to add a new
>>> identifier value (say s390 QEMU PC-BIOS or similar) announcing the new
>>> capabilities, so that a boot server admin can setup her system accordingly.
>>
>> Not sure ... too many processory-architecture-type entries might also
>> rather be too confusing for the users? ... so if 0x20 can also handle
>> binary files like 0x1f, I'd maybe simply go with 0x20 and mainly promote
>> pxelinux config files in the documentation?
>>
> Well, if we don't add another identifier, and I feel reluctant about it
> as well for the reasons you wrote, we may stick with 0x1f and consider
> the additional capabilities as being optional (for special needs only).

I tend to stay with 0x1f, since booting binaries is still the "primary"
interface (the first check for the "default" or "# " magic keywords is
not 100% reliable, since the config file could also start with another
command, and the probing of pxelinux.cfg/* files is only tried afterwards).

 Thomas