svn commit: r316132 - head/sys/boot/i386/boot2

[Warner Losh]

On Wed, Mar 29, 2017 at 3:36 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> --------
> In message <7448826.asYms2TLO2 at ralph.baldwin.cx>, John Baldwin writes:
>>On Wednesday, March 29, 2017 09:30:03 AM Ngie Cooper wrote:
>
>>> Log:
>>>   Parameterize out 7680 (15 * 512) as BOOT2SIZE, similar to sys/boot/i386/zfsboot/...
>>>
>>>   This is being done to make it easier to change in the future--this action might be
>>>   needed sooner rather than later because of gcc 6.3.0 bailing, stating that there
>>>   is negative free space left (deficit) in the boot2 bootloader.
>>>
>>>   MFC after: 2 months
>>>   Sponsored by:      Dell EMC Isilon
>>
>>This can't be changed.  It's baked into the BSD disklabel format.
>
> No it is not, it is baked into FFS, and for UFS2 0, 8, 64 and 256K works.

Technically, this is correct. Practically, I'm not sure we can ever
really change it. There are too many tools, scripts, etc that just
know it's 8k, even though most UFS2 systems start 64k into the volume.
UFS1 systems are still around, and there the limit is a hard limit.
And if we grow it, we run the risk of corrupting data beyond the 8k
area we've traditionally used for this.

So the constants are easy enough to change and it seems like it might
be OK. However, doing it in a safe, anti-foot-shooting way will be the
real elbow grease should someone seriously contemplate the change,
especially since the foot-shooting involved has the potential for
filesystem corruption...

But gcc 6.3 likely just needs a little TLC experimenting with its
different code generation flags...

Warner