Date: Thu, 30 Mar 2017 17:23:10 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Warner Losh <imp@bsdimp.com> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, John Baldwin <jhb@freebsd.org>, Ngie Cooper <ngie@freebsd.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r316132 - head/sys/boot/i386/boot2 Message-ID: <20170330165329.L1061@besplex.bde.org> In-Reply-To: <CANCZdfr2eRRMQy-uwXDhxT0z88CBKwtkg2e_jFBOg%2Bs_L8=FYg@mail.gmail.com> References: <201703290930.v2T9U3x9087583@repo.freebsd.org> <7448826.asYms2TLO2@ralph.baldwin.cx> <46812.1490823365@critter.freebsd.dk> <CANCZdfr2eRRMQy-uwXDhxT0z88CBKwtkg2e_jFBOg%2Bs_L8=FYg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 29 Mar 2017, Warner Losh wrote: > On Wed, Mar 29, 2017 at 3:36 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: >> -------- >> In message <7448826.asYms2TLO2@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170330165329.L1061>