On Tue, Mar 09, 2004 at 03:43:29PM -0500, Matthew Orgass wrote:
> On 2004-03-08 tlaronde@polynum.com wrote:
> 
> > At first glance, it could seem that boostrap + stage 1 + machine
> > dependent operations is what I'm after. But it's not so simple, since
> > the machine-dependent initialization phase does things that are clearly
> > "too much" for a bootloader [parts of the cpu_startup()], mainly the
> > initialization of the system data structures.
> 
>   Why is it "too much" for the bootloader?  If it isn't a matter of space,
> I don't see what the problem is with using the kernel as is (with a
> minimal kernel config).  Boot time could be a concen, but this may be
> fixable to your satisfaction with minimal changes that might also be
> helpful in other situations.  I am not saying that there is nothing you
> can do to improve the use of the kernel as a boot loader, but I think it
> should be looked at from the perspective of optimizing what needs fixing.
> Unless I missed something, I haven't seen you give particular requirements
> that cannot be met without fundamental reductions to the kernel, only a
> few additonal features that are not currently available (primarily, the
> ability to load a new kernel on more ports).

Well, I was still in the mood: "take from the kernel the first part and
throw upon it a limited amount of additionnal work to obtain a
bootloader". Now, with your comments, I realize that indeed the whole
kernel can be a bootloader, and that a significant amount of the work
will have to be put in /usr/sbin/config.

And, indeed, this is almost (kernel== bootloader) at the moment the 
case since we enter interactive autoconf in the kernel, and not in 
the boot program...

> [snip] tips for VM86 taken into account

> 
> > add (the file is present in FreeBSD if I'm not mistaken) the possibility
> > by the bootloader to write an autoconf file (hence, there will be static
> > configuration, and the dynamic autoconfiguration will be the in kernel
> > one + the mask provided by the autoconf file (enable/disable) --- this
> > is already what is made but by hand when entering autoconf (boot -c)).
> 
>   I don't know how FreeBSD does this, but the obvious problem with this
> that I see is that the file can't be accessed until the devices to get to
> it are configured (unless the BIOS/firmware is used).  If the bootloader
> is to be doing the config changes then it could be passed as bootinfo.
> In general, I think it would be best if the file it is kept in is the
> kernel itself.  I don't know how difficult it would be now to create a
> utility that modifies the kernel, although I think the changes made to
> allow userconf are the same ones that would make this possible so it may
> be quite easy.

I haven't look precisely how this is implemented in FreeBSD bootloader,
but since the boot program has to be able to read the FFS, these files
reside in `a' partition in the BSD slice, so there is no problem.

But your suggestion has driven me to this possible solution. Create a
config buffer, a la message buffer, where two distinct kinds of strings
are written:

1) Description of devices found
2) Actions: the classical enable/disable action that one may, at
present, interactively enter when invoking boot -c

On admin demand or on reboot time, this buffer could be saved as an 
additional ELF section (say `.config') to the kernel, this section 
being used to compile a custom kernel, and
being parsed by autoconf at boot time to enable/disable features.

> 
> > I think that if the kernel is stripped done to the strict minimum of
> > drivers, then one can use the full power of NetBSD in the minimal
> > place, that's why I think, I may be wrong, that the bootloader ability
> > must be spartan.
> 
>   I don't understand what you are saying.

My english is not very good, and my ideas were vague. I mean that if we
can achieve (mainly via special config) a small kernel, there is little
incentives to try to develop a special set of userland support in the
bootloader (since bootloader == kernel). Everything shall already be
there.

> 
> > For NFS, since it involves bigger programs, is there the ability to
> > change the rootfs at runtime? I mean, if the kernel is loaded with a
> > minimal MFS which has NFS userland programs, is it possible to load the
> > NFSclient to access the ressources and mount the NFS accessed fs as the
> > root fs overriding the memory image?
> 
>   It is possible, although I don't know if the old root gets completely
> replaced or the new root is mounted on top (I once accedently mounted my
> msdos partition at root and had to reboot via the debugger).  It doesn't
> matter in this case since kernel memory disks are not freeable.  In many
> cases it is possible to mount NFS as root directly with a custom kernel
> config specifying configuratiom parameters.  I don't know what all of the
> limitations of this are.

After some thoughts, I think that there may be at least one problem with
this scheme: if the host using NFSroot starts a cpu and memory intensive
user program, the code for the NFS client (userspace) will be swapped
out. And if the initial programs in the MFS are no longer accessible, a
beautiful panic will follow.
-- 
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C