All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Alexander Graf <agraf@suse.de>,
	qemu-devel@nongnu.org,
	Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Farhan Ali <alifm@linux.vnet.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	Jens Freimann <jfreiman@redhat.com>,
	Eric Farman <farman@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS
Date: Tue, 27 Jun 2017 23:56:12 +0200	[thread overview]
Message-ID: <b4bba4e4-0d69-095e-5fe2-0042bc414093@redhat.com> (raw)
In-Reply-To: <589b8e71-b025-a0ad-0621-d6827e31c90d@suse.de>

On 27.06.2017 23:15, Alexander Graf wrote:
> 
> On 27.06.17 13:48, Thomas Huth wrote:
[...]
>> - The code only supports TFTP (via UDP) ... I think that is OK for
>>    most use-cases, but if we ever want to support network booting
>>    via HTTP or something else that is based on TCP, we would need to
>>    use something else instead... Should we maybe rather head towards
>>    grub2, petitboot or something different instead?
> 
> IMHO the only viable next step would be to support UEFI and build on top
> of that - either by porting edk2 or U-Boot to s390x.

I can't speak of U-Boot, but you certainly don't want to port edk2 to a
big endian machine. Been there, seen that.

> The problem with solutions like petitboot or home grown grub2 targets is
> that it becomes a documentation and knowledge sharing nightmare down the
> road. The less we're different from everyone else, the easier it becomes
> to maintain s390x.

petitboot is basically a Linux system (with a shell, too). And grub2 is
also a common boot loader on x86 nowadays ... so not sure whether they
would really be a knowledge sharing nightmare? I think they would be
more common for "server" people than the U-Boot loader, which is likely
only familiar to "embedded" folks.

 Thomas

  reply	other threads:[~2017-06-27 21:56 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-27 11:48 [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 01/14] pc-bios/s390-ccw: Add the libc from the SLOF firmware Thomas Huth
2017-06-27 15:32   ` David Hildenbrand
2017-06-27 22:14     ` Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 02/14] pc-bios/s390-ccw: Start using the libc from SLOF Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 03/14] pc-bios/s390-ccw: Add a write() function for stdio Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 04/14] pc-bios/s390-ccw: Add implementation of sbrk() Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 05/14] pc-bios/s390-ccw: Add the TFTP network loading stack from SLOF Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 06/14] libnet: Remove remainders of netsave code Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 07/14] libnet: Rework error message printing Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 08/14] libnet: Refactor some code of netload() into a separate function Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 09/14] pc-bios/s390-ccw: Make the basic libnet code compilable Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 10/14] pc-bios/s390-ccw: Add timer code for the libnet Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 11/14] pc-bios/s390-ccw: Add virtio-net driver code Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 12/14] pc-bios/s390-ccw: Load file via an intermediate .INS file Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 13/14] pc-bios/s390-ccw: Allow loading to address 0 Thomas Huth
2017-06-27 11:48 ` [Qemu-devel] [RFC PATCH 14/14] pc-bios/s390-ccw: Wire up the netload code Thomas Huth
2017-06-27 15:41 ` [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS David Hildenbrand
2017-06-27 15:50 ` Viktor Mihajlovski
2017-06-27 21:40   ` Thomas Huth
2017-06-28  7:28     ` Viktor Mihajlovski
2017-06-28  8:02       ` Thomas Huth
2017-06-28 10:56         ` Thomas Huth
2017-06-28 15:02           ` Viktor Mihajlovski
2017-06-29  7:58             ` Thomas Huth
2017-06-29  8:10               ` Viktor Mihajlovski
2017-06-27 16:50 ` Farhan Ali
2017-06-28  7:34   ` Thomas Huth
2017-06-27 21:15 ` Alexander Graf
2017-06-27 21:56   ` Thomas Huth [this message]
2017-06-28  8:06     ` Gerd Hoffmann
2017-06-28  7:43 ` Christian Borntraeger
2017-06-28  8:59   ` Thomas Huth
2017-06-29  8:17     ` Thomas Huth
2017-06-29  8:39       ` Christian Borntraeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b4bba4e4-0d69-095e-5fe2-0042bc414093@redhat.com \
    --to=thuth@redhat.com \
    --cc=agraf@suse.de \
    --cc=alifm@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=farman@linux.vnet.ibm.com \
    --cc=jfreiman@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.