From grub-devel Wed Mar 08 11:46:07 2017 From: Michel Hermier Date: Wed, 08 Mar 2017 11:46:07 +0000 To: grub-devel Subject: Re: Grub2: add UEFI support for accessing memory address above 4GB. Message-Id: X-MARC-Message: https://marc.info/?l=grub-devel&m=148897360902510 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0506176510721572589==" --===============0506176510721572589== Content-Type: multipart/alternative; boundary=94eb2c0d24709eb077054a36ac91 --94eb2c0d24709eb077054a36ac91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le 8 mars 2017 10:58 AM, "Brendan Trotter" a =C3=A9cri= t : 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? Something in the middle, have a well tuned detection, and user defined variable (with a taint mechanism, that *blame/inform* the user that he use a sensible option) --94eb2c0d24709eb077054a36ac91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Le=C2=A08 mars 2017 10:58 AM, "Brendan Trotter" <btrotter@gmail.com> a =C3=A9crit= =C2=A0:
H= i,


> Le 7 mars 2017 17:24, "Vladi= mir 'phcoder' Serbinenko" <phcoder@gmail.com> 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 TFT= P"=C2=A0(with larger/negotiated block size and 16-bit block numbers th= at are allowed to roll over) has no limit at all.


> On Tue, Mar 7, 2017, 09:09 M= ichel Hermier <michel.hermier@gmail.com> wrote:
>
=
> Because I don't trust automatic de= tection. Even if one say it is 200% safe, there is allways that machine tha= t nobody heard of that will fail. So having user being able to force some v= alues is usually a good idea.

What do you think is more reliable: well desig= ned 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 fa= iled=C2=A0read the documentation, thought it did something else, screwed ev= erything up, then blames you for their mistake, then blames you for giving = them the ability to make the mistake?
<= /div>

Something in the m= iddle, have a well tuned detection, and user defined variable (with a taint= mechanism, that *blame/inform* the user that he use a sensible option)
--94eb2c0d24709eb077054a36ac91-- --===============0506176510721572589== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel --===============0506176510721572589==--