On 26.04.2013, at 18:04, Dominik Dingel wrote: > On Fri, 26 Apr 2013 17:48:37 +0200 > Alexander Graf <ag...@suse.de> wrote: > >> >> On 26.04.2013, at 17:42, Christian Borntraeger wrote: >> >>> On 26/04/13 17:22, Alexander Graf wrote: >>>> >>>> On 26.04.2013, at 14:12, Dominik Dingel wrote: >>>> >>>>> Check for a kernel IPL entry and load kernel image if one was >>>>> specified. >>>>> If no kernel image was supplied and the first boot device >>>>> is not a virtio-ccw-blk device, print error message and exit. >>>>> >>>>> In case it is a virtio-ccw-blk device store the dev_no in reg[7] >>>> >>>> I thought we want a boot order, not a singular device to boot off of? >>>> >>>> Alex >>> >>> First of all we want to be able to choose a boot device as a first step. >>> With this patch the user is able to use libvirt and friends to choose the >>> disk to boot from. >>> >>> The nice approach with this bios/ipl device is that we can update both >>> in lock-step so this reg7 interface is not an ABI. >>> >>> So in a future version we actually could: >>> a: implement diag 308 subcode 5/6, which would enable >>> /sys/devices/firmware/[ipl|reipl] >>> just like on z/VM or LPAR (this allows to reboot from a different device). >>> b: implement a list. >>> >>> b looks nice, but I actually prefer a for two reasons: >>> 1. be closer to the real hw >>> 2. predictability >>> but we can certainly discuss this. >>> >>> So I suggest to go with this patch and implement later on what we >>> agree upon? >> >> I don't see how having "first device we find" is any better than a rushed >> interface we need to agree on right before 1.5 hard freeze. Let's just >> release 1.5 with the very simple one and then go for something awesome in >> the next version. >> >> >> Alex > > Okay, I like more the evolution over the revolution kind of approach. So this > patchset does include a few improvements over the :"boot the first blk device > we see" system. > We can specify explicitly with the boot index the device to boot and with > loadparm even the boot entry. > > And I also see it like Christian that this is not really an interface, as it > should be never exposed to the outside. We only enable the outside to use > boot index, which is clearly stated in docs/bootindex.txt and in a later > addition we will enable fallbacks.
Is there any particular reason this can't wait a few weeks, go in early in the 1.6 development cycle and then we see where it carries us? Alex
