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

[Toomas Soome]

> On 30. märts 2017, at 0:55, Warner Losh <imp at bsdimp.com> 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.
>>>> 
>>>>  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
> 

One thing is - for now we know the boot2 has not changed and we do not really expect it to change in large scale anyhow.

Second thing, yes the build process needs to be tested etc, and if needed we can issue statement which compiler we support or not.

And finally - if the space limit is really-really on the way and no other way, then the alternate is to use freebsd-boot partition - nothing new about it.

rgds,
toomas