Date: Thu, 11 Aug 2022 12:26:00 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Warner Losh <imp@FreeBSD.org>, 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 Message-ID: <20220811192600.9F0B4119@slippy.cwsent.com> In-Reply-To: <727af1f3-7432-c038-a776-682ef161f6f9@FreeBSD.org> References: <202208110331.27B3Va7M007335@gitrepo.freebsd.org> <727af1f3-7432-c038-a776-682ef161f6f9@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <imp@FreeBSD.org> > > AuthorDate: 2022-08-11 03:19:01 +0000 > > Commit: Warner Losh <imp@FreeBSD.org> > > 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 <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org e**(i*pi)+1=0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220811192600.9F0B4119>