From nobody Thu Aug 11 19:26:00 2022 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M3cH21nMQz4YTrL; Thu, 11 Aug 2022 19:26:06 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M3cH06Q3pz3FVF; Thu, 11 Aug 2022 19:26:04 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id M8C6oCf38S8WrMDohobmxu; Thu, 11 Aug 2022 19:26:03 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id MDogoPnG9GRNlMDogoASP8; Thu, 11 Aug 2022 19:26:03 +0000 X-Authority-Analysis: v=2.4 cv=Sfrky9du c=1 sm=1 tr=0 ts=62f557cb a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=biHskzXt2R4A:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=4TyKpul207AEUhPkYEMA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 79C00405; Thu, 11 Aug 2022 12:26:01 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 9F0B4119; Thu, 11 Aug 2022 12:26:00 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: John Baldwin cc: Warner Losh , src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: Re: git: 39fdad34e220 - main - stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr In-reply-to: <727af1f3-7432-c038-a776-682ef161f6f9@FreeBSD.org> References: <202208110331.27B3Va7M007335@gitrepo.freebsd.org> <727af1f3-7432-c038-a776-682ef161f6f9@FreeBSD.org> Comments: In-reply-to John Baldwin message dated "Thu, 11 Aug 2022 09:56:30 -0700." List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Aug 2022 12:26:00 -0700 Message-Id: <20220811192600.9F0B4119@slippy.cwsent.com> X-CMAE-Envelope: MS4xfMaPKqsZv/vcjcQ8fSvBB7UCvzfTykA9hh1KD+gk7Jl2fV7+SkOEf4h13YKC/veTZxnp462RLYnOsj4KK+cG2e6k2hZ8P/Vt2v2o0l5rKwndYfc470DP La9TLH16ss6bBqb5pMJBMc287Dw2vOAIsU//hjn5JDlf7DrADURAKFp7N7pUOeH3aPLYExYWDv/2sMrVAtG1QQXntqIObkRocH73e6uug4X86liC0nj8WVDm 0JCXeetkwquE7YRV+tvpwZwqaJ6YEGgNr5aj4VciNol4+kTT6gmUSEiK6r4YWXN/mezwCOH2Wwp3f7N/bG/DOYZnD9F9ao9UZZXnytiAdyG2E2S2fqe17wzi QrJjbrfF X-Rspamd-Queue-Id: 4M3cH06Q3pz3FVF X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-1.80 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org,dev-commits-src-all@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N In message <727af1f3-7432-c038-a776-682ef161f6f9@FreeBSD.org>, John Baldwin wri tes: > On 8/10/22 8:31 PM, Warner Losh wrote: > > The branch main has been updated by imp: > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=39fdad34e220c52a433e78f20c8c39 > 412429014e > > > > commit 39fdad34e220c52a433e78f20c8c39412429014e > > Author: Warner Losh > > AuthorDate: 2022-08-11 03:19:01 +0000 > > Commit: Warner Losh > > CommitDate: 2022-08-11 03:29:20 +0000 > > > > stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr > > > > The BIOS method of booting imposes an absolute limit of 640k for the > > size of the program being run due to btx. In practice, this means that > > programs larger than about 500kiB will fail in odd ways as the stack / > > heap will overflow. > > Technically the heap is now always above 1MB, the issue is the stack growing > down and overwriting .bss. > > > Pick 510,000 as the cutoff line semi-arbitrarily. loader_lua is now > > almost too big and we want to break the build when it crosses this > > threshold. In my experience, below 500,000 always works, above 520,000 > > always seems to fail with things getting bad somewhere between 512,000 > > to 515,000. 510,000 is as close to the line as I think we can go, thou > gh > > experience may dictate we need to lower this in the future. > > > > This is at-best a stop-breakage until we have a better way to subset t > he > > boot loader for BIOS booting to allow better, more fined-tuned > > /boot/loaders for the many different environments they have to run > > in. This likely means we'll have a graphical loader than understands a > > few filesystmes for installation, and a non-graphical loader that > > understands the most filesystems possible for everything else in the > > future. Our build infrastructure needs some work before we can do that > , > > however. > > > > At this late date, it likely isn't worth the efforts to move parts of > > the loader into high memory. There's a number of assumptions about whe > re > > the stack is, where buffers reside, etc that are fulfilled when it liv > es > > in the first 640k that would need bounce buffers and/or other counter > > measures if we were to split it up. All BIOS calls are done in 16-bit > > mode with SEG:OFF addresses, requiring them to be in the first 640k of > > RAM. And nearly all machines in the last decade can boot with UEFI > > (though there's some exceptions, so it isn't worth killing outright > > yet). > > Fully agree that we just want to keep the BIOS loader on a sufficient feature > diet. Agreed. Those with a significant investment in hardware needing upgrade might need sufficient heads up so that they can budget for replacements over time. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=0