Re: WITH_BEARSSL: -8112 bytes available
On Sat, Jun 3, 2023 at 9:03 AM FreeBSD User wrote:
> Am Wed, 31 May 2023 12:15:12 -0600
> Warner Losh schrieb:
>
> Sorry for the late response.
>
>
> > On Mon, May 29, 2023 at 2:59 AM FreeBSD User
> wrote:
> >
> > > Hello,
> > >
> > > on CURRENT, enabling in /etc/src.conf
> > >
> > > WITH_BEARSSL=
> > >
> > > seems to result in a slightly enlarged loader binary, which seems to
> have
> > > a fixed size
> > > supposed on the error I get. See below.
> > >
> > > The system is amd64 (64 bit), for the record.
> > >
> > > Somewhere in the past developers mentioned this upcoming problem and
> > > provided a knob to adjust
> > > the used size - I forgot about that knob and I couldn't find it even in
> > > the loader docs - or
> > > looked at the wrong places.
> > >
> > > Can someone help me out here?
> > >
> > > The first error stops compileing world/kernel, but taking a second run,
> > > the error goes away.
> > >
> > > Kind regards and thanks in advance,
> > >
> > > oh
> > >
> > >
> > >
> > > [...]
> > > --- all_subdir_stand/efi ---
> > > SOURCE_DATE_EPOCH=1451606400 objcopy -j .peheader -j .text -j .sdata
> -j
> > > .data -j .dynamic -j
> > > .dynsym -j .rel.dyn -j .rela.dyn -j .reloc -j .eh_frame -j
> > > set_Xcommand_set -j
> > > set_Xficl_compile_set --output-target=efi-app-x86_64 loader_4th.sym
> > > loader_4th.efi ---
> > > all_subdir_stand/i386 ---
> > >
> > > -8112 bytes available 7.71 real12.86 user 3.08 sys
> >
> >
> > bummer. I hate it when it's that close.
> >
> > You can try setting LOADERSIZE=56 in your environment. We currently
> set
> > the maximum to 550,000
>
> I tried to find find anything related to LOADER or SIZE in the docs. I
> remember you mentioned
> the existence of that variable months ago, but with no clue what to look
> after, it is almost
> impossible yo figure out as a non developer what the right knob might be.
>
Fair point.
> A grep -r on /usr/src shows up only in
>
> [...]
> ./stand/i386/loader/Makefile:LOADERSIZE?= 55 # Largest
> known safe size for
> loader.bin
> ./stand/i386/loader/Makefile: @set -- `ls -l ${.TARGET}` ;
> x=$$((${LOADERSIZE}-$$5)); \
> [...]
>
> There is no sign/trace of it in any man page related to loader and
> sibblings. I found the
> variable rather quickly after knowing what to look after.
>
To be fair, this is a very under documented area, semi on purpose... But
that's a good point that it is
under documented. And now that the size is creeping up and we have options
that explode things,
maybe it should be better documented.
> > bytes because that's the most conservative number due to variation in the
> > available BIOS space available.
> > This likely can be set even higher if you don't have add-in cards that
> are
> > consuming space in the lower 640k
> > of memory. 640k is the absolute limit, but you need 20-30k of stack for
> the
> > loader so pushing this much past
> > 625,000 or maybe 630,000 increases the risk of run-time crashes as the
> > stack smashes through the top of
> > the loader program. You may also have to disable the lua build, since it
> > uses more stack and is just a smidge
> > larger than the forth build. _simp will be the smallest of them all. On
> my
> > system, without bearssl, I see:
> > -r-xr-xr-x 3 root wheel 503808 May 22 15:25 /boot/loader_lua
> > -r-xr-xr-x 1 root wheel 446464 May 22 15:25 /boot/loader_4th
> > -r-xr-xr-x 1 root wheel 385024 May 22 15:25 /boot/loader_simp
>
> In my case, with supposedly blewn up loader size by BEARSSL enables, it is:
>
> -r-xr-xr-x 1 root wheel - 503808 3 Juni 12:33 /boot/loader_4th*
> -r-xr-xr-x 1 root wheel - 643584 3 Juni 12:33 /boot/loader_4th.efi*
> -r-xr-xr-x 1 root wheel - 503808 3 Juni 07:45 /boot/loader_4th.old*
> -r-xr-xr-x 3 root wheel - 569344 3 Juni 12:33 /boot/loader_lua*
> -r-xr-xr-x 2 root wheel - 737280 3 Juni 12:33 /boot/loader_lua.efi*
> -r-xr-xr-x 1 root wheel - 569344 3 Juni 07:45 /boot/loader_lua.old*
> -r-xr-xr-x 1 root wheel - 446464 3 Juni 12:33 /boot/loader_simp*
> -r-xr-xr-x 1 root wheel - 589312 3 Juni 12:33 /boot/loader_simp.efi*
> -r-xr-xr-x 1 root wheel - 446464 3 Juni 07:45 /boot/loader_simp.old*
>
> on FreeBSD 14.0-CURRENT #58 main-n263387-556b43492297: Fri Jun 2 20:19:55
> CEST 2023 amd64.
> > which suggests a ~60k bump for adding forth and ~115k bump for lua. So
> the
> > 560,000 may need to be 625,000
> > which is living life on the edge for 4th, and simply too big for lua.
> >
> > I'd be open to adding docs on this, since I don't think this option is
> > currently documented since I added it
> > to experiment around with a good value.
>
> See above, personally I'd like to see some hints on that variable, even if
> I do not fiddle
> around with it.
>
OK. that makes sense. In fact, it may make sense to disable the build of
the BIOS
loader entirely sometimes, which we can't easily do today.
> >
> > And no, I really do not want to support 'loadable
Re: WITH_BEARSSL: -8112 bytes available
Am Wed, 31 May 2023 12:15:12 -0600
Warner Losh schrieb:
Sorry for the late response.
> On Mon, May 29, 2023 at 2:59 AM FreeBSD User wrote:
>
> > Hello,
> >
> > on CURRENT, enabling in /etc/src.conf
> >
> > WITH_BEARSSL=
> >
> > seems to result in a slightly enlarged loader binary, which seems to have
> > a fixed size
> > supposed on the error I get. See below.
> >
> > The system is amd64 (64 bit), for the record.
> >
> > Somewhere in the past developers mentioned this upcoming problem and
> > provided a knob to adjust
> > the used size - I forgot about that knob and I couldn't find it even in
> > the loader docs - or
> > looked at the wrong places.
> >
> > Can someone help me out here?
> >
> > The first error stops compileing world/kernel, but taking a second run,
> > the error goes away.
> >
> > Kind regards and thanks in advance,
> >
> > oh
> >
> >
> >
> > [...]
> > --- all_subdir_stand/efi ---
> > SOURCE_DATE_EPOCH=1451606400 objcopy -j .peheader -j .text -j .sdata -j
> > .data -j .dynamic -j
> > .dynsym -j .rel.dyn -j .rela.dyn -j .reloc -j .eh_frame -j
> > set_Xcommand_set -j
> > set_Xficl_compile_set --output-target=efi-app-x86_64 loader_4th.sym
> > loader_4th.efi ---
> > all_subdir_stand/i386 ---
> >
> > -8112 bytes available 7.71 real12.86 user 3.08 sys
>
>
> bummer. I hate it when it's that close.
>
> You can try setting LOADERSIZE=56 in your environment. We currently set
> the maximum to 550,000
I tried to find find anything related to LOADER or SIZE in the docs. I remember
you mentioned
the existence of that variable months ago, but with no clue what to look after,
it is almost
impossible yo figure out as a non developer what the right knob might be.
A grep -r on /usr/src shows up only in
[...]
./stand/i386/loader/Makefile:LOADERSIZE?= 55 # Largest known
safe size for
loader.bin
./stand/i386/loader/Makefile: @set -- `ls -l ${.TARGET}` ;
x=$$((${LOADERSIZE}-$$5)); \
[...]
There is no sign/trace of it in any man page related to loader and sibblings. I
found the
variable rather quickly after knowing what to look after.
> bytes because that's the most conservative number due to variation in the
> available BIOS space available.
> This likely can be set even higher if you don't have add-in cards that are
> consuming space in the lower 640k
> of memory. 640k is the absolute limit, but you need 20-30k of stack for the
> loader so pushing this much past
> 625,000 or maybe 630,000 increases the risk of run-time crashes as the
> stack smashes through the top of
> the loader program. You may also have to disable the lua build, since it
> uses more stack and is just a smidge
> larger than the forth build. _simp will be the smallest of them all. On my
> system, without bearssl, I see:
> -r-xr-xr-x 3 root wheel 503808 May 22 15:25 /boot/loader_lua
> -r-xr-xr-x 1 root wheel 446464 May 22 15:25 /boot/loader_4th
> -r-xr-xr-x 1 root wheel 385024 May 22 15:25 /boot/loader_simp
In my case, with supposedly blewn up loader size by BEARSSL enables, it is:
-r-xr-xr-x 1 root wheel - 503808 3 Juni 12:33 /boot/loader_4th*
-r-xr-xr-x 1 root wheel - 643584 3 Juni 12:33 /boot/loader_4th.efi*
-r-xr-xr-x 1 root wheel - 503808 3 Juni 07:45 /boot/loader_4th.old*
-r-xr-xr-x 3 root wheel - 569344 3 Juni 12:33 /boot/loader_lua*
-r-xr-xr-x 2 root wheel - 737280 3 Juni 12:33 /boot/loader_lua.efi*
-r-xr-xr-x 1 root wheel - 569344 3 Juni 07:45 /boot/loader_lua.old*
-r-xr-xr-x 1 root wheel - 446464 3 Juni 12:33 /boot/loader_simp*
-r-xr-xr-x 1 root wheel - 589312 3 Juni 12:33 /boot/loader_simp.efi*
-r-xr-xr-x 1 root wheel - 446464 3 Juni 07:45 /boot/loader_simp.old*
on FreeBSD 14.0-CURRENT #58 main-n263387-556b43492297: Fri Jun 2 20:19:55 CEST
2023 amd64.
> which suggests a ~60k bump for adding forth and ~115k bump for lua. So the
> 560,000 may need to be 625,000
> which is living life on the edge for 4th, and simply too big for lua.
>
> I'd be open to adding docs on this, since I don't think this option is
> currently documented since I added it
> to experiment around with a good value.
See above, personally I'd like to see some hints on that variable, even if I do
not fiddle
around with it.
>
> 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.
> 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
Re: WITH_BEARSSL: -8112 bytes available
> On 1. Jun 2023, at 11:30, Gary Jennejohn wrote: > > On Wed, 31 May 2023 14:41:23 -0600 > Warner Losh mailto:i...@bsdimp.com>> wrote: > >> On Wed, May 31, 2023 at 1:30?PM Gary Jennejohn wrote: >> >>> On Wed, 31 May 2023 12:15:12 -0600 >>> Warner Losh 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. >> > > OK, that makes sense. If it disappears after 15 I guess I'll have to > maintain it myself. Should be doable. > > I have this change in my queue: https://reviews.freebsd.org/D40375 toomas
Re: WITH_BEARSSL: -8112 bytes available
On Wed, 31 May 2023 14:41:23 -0600 Warner Losh wrote: > On Wed, May 31, 2023 at 1:30?PM Gary Jennejohn wrote: > > > On Wed, 31 May 2023 12:15:12 -0600 > > Warner Losh 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. > OK, that makes sense. If it disappears after 15 I guess I'll have to maintain it myself. Should be doable. -- Gary Jennejohn
Re: WITH_BEARSSL: -8112 bytes available
On Wed, May 31, 2023 at 1:30 PM Gary Jennejohn wrote: > On Wed, 31 May 2023 12:15:12 -0600 > Warner Losh 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
Re: WITH_BEARSSL: -8112 bytes available
> the loader program. You may also have to disable the lua build, since it uses > more stack and is just a smidge > larger than the forth build. _simp will be the smallest of them > all. On my system, without bearssl, I see: Back when I first did the LOADER_VERIEXEC bits, I found lua pushed things over the edge. We use 4th anyway, and will likely be stuck with it for another decade at least. > -r-xr-xr-x 3 root wheel 503808 May 22 15:25 /boot/loader_lua > -r-xr-xr-x 1 root wheel 446464 May 22 15:25 /boot/loader_4th > -r-xr-xr-x 1 root wheel 385024 May 22 15:25 /boot/loader_simp > which suggests a ~60k bump for adding forth and ~115k bump for lua. So the > 560,000 may need to be 625,000 > which is living life on the edge for 4th, and simply too big for lua. > > I'd be open to adding docs on this, since I don't think this option is > currently documented since I added it > to experiment around with a good value. My own experiments found somewhere around 550k to be the limit. > 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. > 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 Yes. For those of us with serial only consoles, the graphics stuff is pure overhead. > Without the extras and ZFS, you might have bearssl and lua together even... FWIW our i386 loader with BEARSSL and LOADER_VERIEXEC and 4th rather than lua is 312K I can get that down to 308K by dropping LOADER_EXT2FS_SUPPORT which I am pretty sure we don't need. If I enable lua and disable 4th, the loader is still only 352K in our stable/12 branch and 364K in main I just did a quick test on a VM - that loader_lua was able to load kernel ok, so looks promising. Of course we have 8k lines of 4th that would need translating to lua before I could be sure. --sjg
Re: WITH_BEARSSL: -8112 bytes available
On Wed, 31 May 2023 12:15:12 -0600 Warner Losh 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, 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. -- Gary Jennejohn
Re: WITH_BEARSSL: -8112 bytes available
On Mon, May 29, 2023 at 2:59 AM FreeBSD User wrote: > Hello, > > on CURRENT, enabling in /etc/src.conf > > WITH_BEARSSL= > > seems to result in a slightly enlarged loader binary, which seems to have > a fixed size > supposed on the error I get. See below. > > The system is amd64 (64 bit), for the record. > > Somewhere in the past developers mentioned this upcoming problem and > provided a knob to adjust > the used size - I forgot about that knob and I couldn't find it even in > the loader docs - or > looked at the wrong places. > > Can someone help me out here? > > The first error stops compileing world/kernel, but taking a second run, > the error goes away. > > Kind regards and thanks in advance, > > oh > > > > [...] > --- all_subdir_stand/efi --- > SOURCE_DATE_EPOCH=1451606400 objcopy -j .peheader -j .text -j .sdata -j > .data -j .dynamic -j > .dynsym -j .rel.dyn -j .rela.dyn -j .reloc -j .eh_frame -j > set_Xcommand_set -j > set_Xficl_compile_set --output-target=efi-app-x86_64 loader_4th.sym > loader_4th.efi --- > all_subdir_stand/i386 --- > > -8112 bytes available 7.71 real12.86 user 3.08 sys bummer. I hate it when it's that close. You can try setting LOADERSIZE=56 in your environment. We currently set the maximum to 550,000 bytes because that's the most conservative number due to variation in the available BIOS space available. This likely can be set even higher if you don't have add-in cards that are consuming space in the lower 640k of memory. 640k is the absolute limit, but you need 20-30k of stack for the loader so pushing this much past 625,000 or maybe 630,000 increases the risk of run-time crashes as the stack smashes through the top of the loader program. You may also have to disable the lua build, since it uses more stack and is just a smidge larger than the forth build. _simp will be the smallest of them all. On my system, without bearssl, I see: -r-xr-xr-x 3 root wheel 503808 May 22 15:25 /boot/loader_lua -r-xr-xr-x 1 root wheel 446464 May 22 15:25 /boot/loader_4th -r-xr-xr-x 1 root wheel 385024 May 22 15:25 /boot/loader_simp which suggests a ~60k bump for adding forth and ~115k bump for lua. So the 560,000 may need to be 625,000 which is living life on the edge for 4th, and simply too big for lua. I'd be open to adding docs on this, since I don't think this option is currently documented since I added it to experiment around with a good value. 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. 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. Warner
Re: WITH_BEARSSL: -8112 bytes available
Hi, On Mon, May 29, 2023 at 10:58:27AM +0200, FreeBSD User wrote: > on CURRENT, enabling in /etc/src.conf > > WITH_BEARSSL= > > seems to result in a slightly enlarged loader binary, which seems to have a > fixed size > supposed on the error I get. See below. > > The system is amd64 (64 bit), for the record. > > Somewhere in the past developers mentioned this upcoming problem and provided > a knob to adjust > the used size - I forgot about that knob and I couldn't find it even in the > loader docs - or > looked at the wrong places. > > Can someone help me out here? > > The first error stops compileing world/kernel, but taking a second run, the > error goes away. > > Kind regards and thanks in advance, > > oh > > > > [...] > --- all_subdir_stand/efi --- > SOURCE_DATE_EPOCH=1451606400 objcopy -j .peheader -j .text -j .sdata -j > .data -j .dynamic -j > .dynsym -j .rel.dyn -j .rela.dyn -j .reloc -j .eh_frame -j set_Xcommand_set > -j > set_Xficl_compile_set --output-target=efi-app-x86_64 loader_4th.sym > loader_4th.efi --- > all_subdir_stand/i386 --- > > -8112 bytes available 7.71 real12.86 user 3.08 sys > > make[1]: stopped in /usr/src > [...] I often face a similiar error, not sure if it is BEARSSL related since I build it since a few month per default, but it often helps just to restart the build. --Gordon signature.asc Description: PGP signature
