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

[Bruce Evans]

On Wed, 29 Mar 2017, Warner Losh wrote:

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

No, it is not.  It is only in default disk layouts where the file system
leaves space for a boot block and this space is actually used for a boot
block, and someone with a name like phk changed the default layout long
ago.

> Technically, this is correct. Practically, I'm not sure we can ever
> really change it. There are too many tools, scripts, etc that just

You mean, practically this is correct :-).  The ffs limit is irrelevant
in theory except for small media, and even 80K floppies could afford
a bit more than 8K for boot blocks in emergency.  But in practice,
the ffs1 limit is still relevant since default disk layouts were only
changed 10-15 years ago.

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

ffs2 is not needed.  I copy partitions a little higher to make space
for boot blocks before all partitions.  This is mostly on old disks
that don't have room for expansion, but it is usually possible to
find a spare 8M, possibly by removing the swap partition.  But I
haven't done this for my oldest disks, so still need the 8K boot blocks
for portability.

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

It takes me too long to move partitions manually.  Doing this robustly
in an automatic way would be difficult.

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

I doubt that gcc-6.3 is very broken.  Did its CFLAGS even have -Os?
Kernel CFLAGS are still broken even for gcc-4.2, by sprinkling inline
parameter magic that was more needed for gcc-3.3.  The magic isn't
really right for gcc-4.2, and breaks -Os for kernels.  The magic might
be wronger for gcc-6.3, though it would be a compiler bug to not
just ignore it if it is nonsense.  clang doesn't provide any control
over inlining AFAIK, but ignores gcc directive to limit it and does
too much.

Bruce