From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1clYLw-0008Vt-Bi for mharc-grub-devel@gnu.org; Wed, 08 Mar 2017 04:57:52 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51275) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clYLu-0008Vj-BV for grub-devel@gnu.org; Wed, 08 Mar 2017 04:57:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clYLt-0004sP-Fj for grub-devel@gnu.org; Wed, 08 Mar 2017 04:57:50 -0500 Received: from mail-qk0-x22b.google.com ([2607:f8b0:400d:c09::22b]:36794) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1clYLt-0004sK-AP for grub-devel@gnu.org; Wed, 08 Mar 2017 04:57:49 -0500 Received: by mail-qk0-x22b.google.com with SMTP id 1so55823009qkl.3 for ; Wed, 08 Mar 2017 01:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=hkuBKWAdKU9ZtWsixdtB8+YthtSSyARiNGM1Pg3gWvM=; b=Z7SgCPq7E1+ZuHHBqlg6qT/Jvsot1EYuRljs7E141dmTZThGHQLKvJkzCfynvRizb5 ViTQBDRbn2xhuS5G8hpNtZ87LWIvbFQ5I1FKoittM177lL79VAbIVhaO6gKwfWEogtj0 2DAKELDo2jY4o5rBkExoreeXACKJTaWWSpb7s+eagsbA+X1DYsn8CFE6rZE3QY0VzuiC Lts3FbaVUclJvMW6dIXAbqZSFht2JKi4xiTRX3TsnNRA9cMOdND85zrFmZVBWUqNrIoA M80B/O51EkuBKlYKUglIk//WM1dIdRtZsMlOYQkzgtPaaypDX+/mTKi4bpsK9C5ahAYo QgFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=hkuBKWAdKU9ZtWsixdtB8+YthtSSyARiNGM1Pg3gWvM=; b=d7wg2/nwUA5LHOG9eKKKUkFjUSWZPiJ8ZueMkEKknvvPseRUIt8pkcLyuLPhOcGESk iqX4JHCwSJx5BnMK85tmUE0vNsc+zodnl1WcUxXwziUDP6IB6aPa/XUQVC1A2Wmbp4Go +774giWDYcKD9YaMrPtpaXMZs/sK7H32qEU8gf0iUnlfqzxMj//790poZxgw7QTQz+Kn 4ZE9QSgP3lcJdMN5TKucVf/jVDfesDdyLqk66JTMX7PmTYV+4yzbwHCqdHr3nJTJJddX 6MEzAtfyfUekD7YyCHqZwTheCfaCueEmSmvZETPxCKiX51sHeqtXLhdVY6JUbHHz9nfR ur8g== X-Gm-Message-State: AMke39nCoJhzh5O8t9EAzo+28ffGTte6Qs08DSEiNYSnQsT8dNIMNSqQhgnXwB2zvSbRWlTBBtJd2WTsobIFtA== X-Received: by 10.129.79.83 with SMTP id d80mr1305888ywb.64.1488967066444; Wed, 08 Mar 2017 01:57:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.96.84 with HTTP; Wed, 8 Mar 2017 01:57:45 -0800 (PST) In-Reply-To: References: <0F096E795C1FFC47A7AE6BB0F7A9C1764BDD05B1@nkgeml513-mbs.china.huawei.com> <20170307155811.GM16034@bivouac.eciton.net> From: Brendan Trotter Date: Wed, 8 Mar 2017 20:27:45 +1030 Message-ID: Subject: Re: Grub2: add UEFI support for accessing memory address above 4GB. To: The development of GNU GRUB Content-Type: multipart/alternative; boundary=001a114ddc8013ec10054a3529cb X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c09::22b X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 09:57:51 -0000 --001a114ddc8013ec10054a3529cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, > Le 7 mars 2017 17:24, "Vladimir 'phcoder' Serbinenko" a =C3=A9crit : > > I'd like to know more about the usecase. Generally you should avoid downloading or loading too large files in bootloader. I.a. TFTP protocol has problems with files over about 100MIB. Generally you should download only kernel + initrd and rest of the system should be on iSCSI or NFS. "Ancient TFTP" (with 512-byte blocks and 16-bit block numbers that aren't allowed to roll over) has problems with files over 32 MiB. "Modern TFTP" (with larger/negotiated block size and 16-bit block numbers that are allowed to roll over) has no limit at all. > On Tue, Mar 7, 2017, 09:09 Michel Hermier wrote: > > Because I don't trust automatic detection. Even if one say it is 200% safe, there is allways that machine that nobody heard of that will fail. So having user being able to force some values is usually a good idea. What do you think is more reliable: well designed auto-detection code that was written and tested by competent developer/s that know exactly what they're doing and why; or a random user who failed read the documentation, thought it did something else, screwed everything up, then blames you for their mistake, then blames you for giving them the ability to make the mistake? Cheers, Brendan --001a114ddc8013ec10054a3529cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

> Le 7 mars 2017 17:24, "Vladimir '= phcoder' Serbinenko" <phco= der@gmail.com> a =C3=A9crit :
>
> I'd like to know = more about the usecase. Generally you should avoid downloading or loading t= oo large files in bootloader. I.a. TFTP protocol has problems with files ov= er about 100MIB. Generally you should download only kernel + initrd and res= t of the system should be on iSCSI or NFS.

&quo= t;Ancient TFTP" (with 512-byte blocks and 16-bit block numbers that ar= en't allowed to roll over) has problems with files over 32 MiB. "M= odern TFTP"=C2=A0(with larger/negotiated block size and 16-bit block n= umbers that are allowed to roll over) has no limit at all.


> On Tue, Mar 7, 2017, 09:09 Michel Hermier <= michel.hermier@gmail.com>= ; wrote:
>
> Because I don't trust automa= tic detection. Even if one say it is 200% safe, there is allways that machi= ne that nobody heard of that will fail. So having user being able to force = some values is usually a good idea.

What do you think is more reliable: well = designed auto-detection code that was written and tested by competent devel= oper/s that know exactly what they're doing and why; or a random user w= ho failed=C2=A0read the documentation, thought it did something else, screw= ed everything up, then blames you for their mistake, then blames you for gi= ving them the ability to make the mistake?

<= div style=3D"">
Cheers,

<= /div>
Brendan

--001a114ddc8013ec10054a3529cb--