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
