[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Restrictions of libnet (was: Re: VW ELF loader)

From: Thomas Huth
Subject: Restrictions of libnet (was: Re: VW ELF loader)
Date: Tue, 4 Feb 2020 10:20:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 04/02/2020 09.54, Cornelia Huck wrote:
> On Tue, 4 Feb 2020 07:16:46 +0100
> Thomas Huth <address@hidden> wrote:
>> On 04/02/2020 00.26, Paolo Bonzini wrote:
>>> Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy <address@hidden
>>> <mailto:address@hidden>> ha scritto:
>>>     Speaking seriously, what would I put into the guest?
>>> Only things that would be considered drivers. Ignore the partitions
>>> issue for now so that you can just pass the device tree services to QEMU
>>> with hypercalls.
>>>     Netboot's dhcp/tftp/ip/ipv6 client? It is going to be another SLOF,
>>>     smaller but adhoc with only a couple of people knowing it.
>>> You can generalize and reuse the s390 code. All you have to write is the
>>> PCI scan and virtio-pci setup.  
>> Well, for netbooting, the s390-ccw bios uses the libnet code from SLOF,
>> so re-using this for a slim netboot client on ppc64 would certainly be
>> feasible (especially since there are also already virtio drivers in SLOF
>> that are written in C), but I think it is not very future proof. The
>> libnet from SLOF only supports UDP, and no TCP. So for advanced boot
>> scenarios like booting from HTTP or even HTTPS, you need something else
>> (i.e. maybe grub is the better option, indeed).
> That makes me wonder what that means for s390: We're inheriting
> libnet's limitations, but we don't have grub -- do we need to come up
> with something different? Or improve libnet?

I don't think that it makes sense to re-invent the wheel yet another
time and write yet another TCP implementation (which is likely quite a
bit of work, too, especially if you also want to do secure HTTPS in the
end). So yes, in the long run (as soon as somebody seriously asks for
HTTP booting on s390x) we need something different here.

Now looking at our standard s390x bootloader zipl - this has been giving
us a headache a couple of times in the past, too (from a distro point of
view since s390x is the only major platform left that does not use grub,
but also from a s390-ccw bios point of view, see e.g.
https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg03046.html and
related discussions).

So IMHO the s390x world should move towards grub2, too. We could e.g.
link it initially into the s390-ccw bios bios ... and if that works out
well, later also use it as normal bootloader instead of zipl (not sure
if that works in all cases, though, IIRC there were some size
constraints and stuff like that).

Just my 0.02 € of course, though.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]