On 28.06.2017 10:59, Thomas Huth wrote: > On 28.06.2017 09:43, Christian Borntraeger wrote: >> Interesting work, thanks for giving it a ry. >> >> On 06/27/2017 01:48 PM, Thomas Huth wrote: >>> It's already possible to do a network boot of an s390x guest with an >>> external netboot image (based on a Linux installation), but it would >>> be much more convenient if the s390-ccw firmware supported network >>> booting right out of the box, without the need to assemble such an >>> external image first. >>> >>> This patch series now introduces network booting via DHCP and TFTP >>> directly into the s390-ccw firmware by re-using the networking stack >>> from the SLOF firmware (see https://github.com/aik/SLOF/ for details), >>> and adds a driver for virtio-net-ccw devices. >> >> What is the licensing situation with SLOF? > > All its code is licensed under the 3-Clause BSD License: > > https://github.com/aik/SLOF/blob/master/LICENSE > > AFAIK it should be fine to use such code in GPL-ed sources like the > s390-ccw firmware, shouldn't it? > >>> - Is it OK to require loading an .INS file first? Or does anybody >>> have a better idea how to load multiple files (kernel, initrd, >>> etc. ...)? >> >> I agree with Viktor that supporting a pxelinux config file is probably the >> better way, since this is what all exisiting servers admins understand. For >> the time being Linux will be the most relevant guest and requiring changes in >> management infrastructure will certainly make things very hard. > > I have to say, the more I read about pxelinux, the more I think we > should *not* directly support this in the firmware. pxelinux is clearly > a secondary stage bootloader, with a rather complex config file, and > features like config file name guessing via MAC-address or IP-address > ... if we really want to support that on s390x, too, I think it should > stay in a external binary instead, and not directly incorporated into > the s390-ccw firmware (so that users finally have the choice whether > they want to use pxelinux-style config files or grub2 or something > different one day). > > I guess the .INS file parsing in firmware was already a bad idea... all > other typical firmware implementations can also only load one file - and > if you need to load multiple files, you've got to use a secondary stage > bootloader like pxelinux, yaboot or grub2. So if we agree to add network > booting directly into the s390-ccw firmware, I think we should do the > same here and only support loading of one file (without an additional > config file). But then the question is, of course, whether it makes > sense to add that support to the firmware at all, or whether we should > simply continue with the current "s390-netboot.img" secondary-loader > approach... > >>> - The code from SLOF uses a different coding style (TABs instead >>> of space) ... is it OK to keep that coding style here so we >>> can share patches between SLOF and s390-ccw more easily? >> >> Is it possible to enhance SLOF and then link to the existing SLOF code? > > I already submitted some of the clean-up patches to the SLOF mailing > list, and Alexey has merged them now, e.g.: > > https://github.com/aik/SLOF/commit/140c3f39db4ce4c0 > > And as I already mentioned in my reply to David, it should theoretically > be possible to use the code from the roms/SLOF submodule in QEMU ... > but then we've got to deal with sudden changes in the SLOF repository > which might cause unwanted problems in the s390-ccw firmware. I guess we > could give it a try (the libc code is very, very stable in SLOF, and the > libnet code also changes only very seldomly) - of course only if we > really decide that we want to have TFTP support directly in the > firmware. If we rather want to continue with the s390-netboot.img > approach instead, I have got to reconsider whether I continue with my > efforts by putting that stuff into an external binary, or whether it > makes more sense to look into porting pxelinux, grub2 or petitboot > instead...
OK, thinking about all of this again, what do you think of the following approach: Let's do not include network booting code into the s390-ccw.img, but keep the way that it uses an external s390-netboot.img for this job. I'll then try to add an additional s390-netboot.img target to the Makefile, which will only be built if the roms/SLOF submodule has been checked out. That target then uses the libc and libnet from the SLOF submodule and links it with my virtio-net driver and some other required code from the s390-ccw bios into a s390-netboot.img binary that can be used for network booting. This way ... - the main s390-ccw.img stays independent from the changes in the SLOF, and we can tackle possible problems in the s390-netboot.img independently. And we don't have to deal with coding style issues in the libc and libnet. - we can ship a s390-netboot.img with QEMU directly, so that network booting is possible out of the box without forcing the users / downstream distros to figure out how to build a netboot.img on their own - we keep the possibility to use alternative s390-netboot.imgs in case the users need advanced features like booting via HTTP Does that sound like an acceptable strategy? Thomas