kernel memory checks on boot vs. boot time

[Bruce Evans]

On Thu, 24 Mar 2011, Gary Jennejohn wrote:

> On Wed, 23 Mar 2011 23:22:09 +0000
> Alexander Best <arundel at freebsd.org> wrote:
>
>> On Thu Mar 24 11, Andriy Gapon wrote:
>>> on 23/03/2011 22:50 Oliver Fromme said the following:
>>>> Beware, I don't know if this is the *only* thing preventing
>>>> boot2 from booting an amd64 kernel.  There might be more.

["This" is setting up long mode.]  I think amd64 also depends on loader
to set up lots of page table, ELF and module stuff.  Compare the size of
amd64.locore.S with the size of i386/locore.s.  I'm not sure how much
of the simplification is automatic from using long mode.

>>>> I haven't tried booting FreeBSD without the boot loader in
>>>> a long time.  Probably not in this century.

Since I consider the existence of loader to be a bug, I try not to use it,
and mostly use my version of biosboot (= biosboot with elf support copied
from boot2) on i386.

>>> Kind of hijacking the thread - while we are gradually moving from mbr+bsdlabel
>>> to gpt and more, we are also moving from away from size-constrained boot2.

This has been possible since ~1980 using disklabel.  Either put the boot2
stage on a separate partition, or fix assumptions that the space reserved
for the boot area (d_bbsize) is always 8K.

>>> My vision is that boot2 and loader should fuse into something more powerful that
>>> would reside in a boot partition, but with its config files on a "regular"
>>> filesystem.

My vision was that this would be named "/kernel".  There might still
be a boot2 stage, but it would have as many full kernel features as
you want, to prepare for the full kernel, or perhaps for a reduced
kernel.  Unfortunately, in FreeBSD, instead of merging the second stage
into the kernel, the second stage was split into boot2 and a loader
stage, with enormous bloat in the loader stage.  Yet the bloat isn't
large enough to include necessary functionality for handling itself,
starting with command line editing and history various search functions.

>> +1. being able to control the whole boot process by /etc/boot.conf would be
>> great. there are defenately too many files in /boot. new users have no clue
>> what boot, boot0, boot1, boot2, cdboot, gptboot, etc. are all about.
>>
>> merging /boot/loader, /boot/gptboot and /boot/zfsgptboot would be really nice.
>> building/installing all the mbr+bsdlabel boot files could be made dependable
>> upon some variable (WITH_MBR_BOOT=), which could be disabled by default.
>>
>> also moving away from forth to something more modern might be thinkable. having
>> support for a modern scripting language might make it easier to come up with a
>> nice graphical bootloader e.g. there're probably more advantages.
>>
>> problem might be that the current gpart(8) manual recommends using 64k for the
>> boot partition. that might not be enough, if ada0p1 should contain the
>> functionality of all boot stages (including the loader), support for a modern
>> scripting language and support for graphical menues (including a rudimentary
>> vga/vesa driver for high res).
>
> I have no problem with any of these ideas as long as well-documented
> knobs are provided to turn these "features" off and maintain "legacy"
> functionality.
>
> I'm running off disks where FreeBSD was installed 8 years ago and I have
> no intention of using gpart(8) on any of them.  The same goes for
> graphical bootloaders - I can't stand them.

Me too.  However, I liked userconfig and even the semi-graphical visual
userconfig in FreeBSD-[2-4].  These were correctly placed from my point
of view (in the kernel), and were optional so not using them was
supported.

Bruce