Date: Wed, 31 May 2023 19:30:26 +0000 From: Gary Jennejohn <garyj@gmx.de> To: Warner Losh <imp@bsdimp.com> Cc: FreeBSD User <freebsd@walstatt-de.de>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: WITH_BEARSSL: -8112 bytes available Message-ID: <20230531213026.275c4eaf@ernst.home> In-Reply-To: <CANCZdfo-PojzQrL5ppxSLLfp%2B5f-ToqQD_N3p3aYtEKBodQ7xQ@mail.gmail.com> References: <20230529105854.1903226d@thor.intern.walstatt.dynvpn.de> <CANCZdfo-PojzQrL5ppxSLLfp%2B5f-ToqQD_N3p3aYtEKBodQ7xQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 31 May 2023 12:15:12 -0600 Warner Losh <imp@bsdimp.com> wrote: [SNIP irrelevant text] > And no, I really do not want to support 'loadable modules'. BIOS booting= is > on the way out, and people > that want to do complex stuff in the boot loader will simply have to do > that in UEFI or maybe kboot/LinuxBoot. So, what exactly does "BIOS booting is on the way out" mean? I have four computers which use BIOS booting. Three are too old to support UEFI and the other one I simply set to BIOS booting out of habit. The only computer I have which uses UEFI is a laptop which was already set up to use UEFI and I was too lazy to change it. > There's low RoI on adding this complexity, imho. We'd be better off, imh= o, > making things like the graphics > console optional since the fonts and code for that free up about 30k in > stupid experiments that I've done > (it's hard since vidconsole has a lot of calls into the graphics system > that aren't optional and easy to disable, > so I've had to do hack and slash to produce a super ugly result that is > only suggestive of the final savings): > -rw-r--r-- 1 imp imp 352256 May 31 12:04 loader_simp > I don't know if I slashed too much, or not enough since the code is rath= er > hard to separate out, so if you > really wanted to go down this path, it would take a lot of work and pati= ent > understanding to make it so with > the low end of savings 20k and the high end on the order of maybe 40k. > > There's likely other ways to conserve space. We've not had space issues > with loader, et al, in the past, > so it's not well setup for subsetting. Though the different filesystem > support might also net you a fair amount: > LOADER_NET_SUPPORT?=3D yes > LOADER_NFS_SUPPORT?=3D yes > LOADER_TFTP_SUPPORT?=3D yes > LOADER_CD9660_SUPPORT?=3D yes > LOADER_EXT2FS_SUPPORT?=3D yes > LOADER_MSDOS_SUPPORT?=3D yes > LOADER_UFS_SUPPORT?=3D yes > LOADER_GZIP_SUPPORT?=3D yes > LOADER_BZIP2_SUPPORT?=3D yes > as would compiling w/o ZFS, which uses its own method (eg > WITHOUT_LOADER_ZFS). Tuning the loader > at this level does start to get into the weeds a bit, but can offer ~40k > savings turning off all but NET and UFS: > -rw-r--r-- 1 imp imp 344064 May 31 12:11 loader_simp > you get even about ~100k when you disable ZFS support with > -DWITHOUT_LOADER_ZFS: > -rw-r--r-- 1 imp imp 241664 May 31 12:12 loader_simp > (both of these are with the graphics console enabled without the silly > hacks to see how much that takes up). > Without the extras and ZFS, you might have bearssl and lua together even= ... > > Hope this helps. > This is interesting information. =2D- Gary Jennejohn
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230531213026.275c4eaf>