Re: WITH_BEARSSL: -8112 bytes available

On Wed, May 31, 2023 at 1:30 PM Gary Jennejohn <garyj@gmx.de> wrote:

> 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.
>

New computers aren't supporting it. Its days are numbered. It's longevity is
much shorter than UEFI's. These are all indisputable. I'm not planning on
dropping it in 15, but the number of people that are using it is a declining
group over time. Time spent making EFI more effective will affect more
people. That's what I mean. So I don't want to sink a ton of time into it.


> 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,
> imho,
> > 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
> rather
> > hard to separate out, so if you
> > really wanted to go down this path, it would take a lot of work and
> patient
> > 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?=    yes
> > LOADER_NFS_SUPPORT?=    yes
> > LOADER_TFTP_SUPPORT?=   yes
> > LOADER_CD9660_SUPPORT?= yes
> > LOADER_EXT2FS_SUPPORT?= yes
> > LOADER_MSDOS_SUPPORT?=  yes
> > LOADER_UFS_SUPPORT?=    yes
> > LOADER_GZIP_SUPPORT?=   yes
> > LOADER_BZIP2_SUPPORT?=  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.
>

Thanks!

Warner