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

[Warner Losh]

On Wed, Mar 29, 2017 at 7:24 PM, Warner Losh <imp at bsdimp.com> wrote:
>
>
> On Mar 29, 2017 7:04 PM, "Ngie Cooper" <yaneurabeya at gmail.com> wrote:
>
> On Wed, Mar 29, 2017 at 3:14 PM, Toomas Soome <tsoome at me.com> wrote:
>
> ...
>
>> 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.
>
> Great! I didn't figure that it could be changed (given recent
> discussions). I'll add a nice comment and open a CR/get it right so
> it's clear why it's 7680. I (for instance) didn't understand exactly
> why the limit was that way. It helps to document these things for
> interested parties :).
>
>
> Because it's 8k minus 512 bytes that boot1 consumes. We could gain a few
> bytes by combining the two, but that gets complicated. And I think people
> are underestimatin just how ingrained this assumption is outside of file
> system code...
>
> But this is just a legacy issue. Uefi kills these limits.
>
> I'm working on automating finding the optimal set of options to use for size
> so it isn't tedious trial and error. It's totally a non issue today. 6.3
> isn't supported at all. Someday we may need to cope, but we have the luxury
> of time on this.

And also for some perspective, the original ZORK game was only 7720
bytes in length... Granted that was on the pdp-11 on 8th edition
research Unix, but I spent more hours playing that came that I have
interacting with boot2.... That's only 40 bytes more than the boot2
limit...

Warner