On Fri, 9 Jan 2009, Jean McCormack wrote: > Tycho Nightingale wrote: >> >> On Thu, 8 Jan 2009, Jean McCormack wrote: >> >>> Please review the following fixes >>> >>> >>> CR: >>> 5887 DC needs to install boot blocks to sparc bootroot >>> http://defect.opensolaris.org/bz/show_bug.cgi?id=5887 >>> >>> 5888 /platform/[sun4u|sun4v]/wanboot is needed in AI image >>> http://defect.opensolaris.org/bz/show_bug.cgi?id=5888 >>> >>> Webrev: >>> http://cr.opensolaris.org/~jeanm/slim_5888_5887/ >> >> The path to the bootblock with an embedded 'sun4u' may break on >> 'sun4v' systems. It's probably best to use: >> >> /usr/platform/`uname -m`/lib/fs/ufs/bootblk > There's actually 2 reasons not to. 1) You could be building on a > different architecture than what you will run on. Thus uname -m might return > a different platform anyway. 2) I was told (2nd hand) that Jan > recommended using sun4u. Since he's the boot guy I figured this was correct.
This brings up a fundamental issue. The resulting image must work for both sun4u and sun4v systems and hence the installed boot block must support both systems. Today the sun4u and sun4v boot blocks are built from a single forth source file, so luckily you are fine using either. However, the point I was making was the the boot block for the current architecture is more likely to be on the build system than the block block for a specific architecture, so the build has a greater chance of working and not failing because of a missing file. But in the future if the boot blocks diverge this entire strategy crumbles. Tycho
