Re: modules_enabled in kernel ELF note section

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

> > options MEMORY_DISK_DYNAMIC ?
> 
> miniroot.kmod works in an automagical way.  I'm afraid that it's a
> bad concidence to keep adding  MD_HOOK_BOO to solve situations.

Fortunately MEMORY_DISK_DYNAMIC is already in options(4).

> > We have to move boot.cfg(5) support and loading module 
> > functions from i386/stand to MI libsa, I think.
> 
> I feel hesitated to do so since it's somehow "grub'ing" way to
> pursue imaginary (and not-existing) universal loaders and would
> limit creative imagination to florish.  Scripting and even command
> line editing for debug would be possible and all heavily depend
> on targets to port and how to use it in field.

We can still imagine more specific existing structures:
- functions that load modules could be in MI as libsa/loadfile.c for kernels
- bootinfo structures that pass module info etc. to a loaded kernel
  are MD (unfortunately)
- some ports don't bother to implement getchar()
  (i.e. all args are passed via PROM prompt)
- some ports cannot have tgets() (gets() with timeout)
  due to firmware limitation etc.
- we cannot implement "timeout-then-default" method without tgets()
- loading and parsig boot.cfg(5) functions could be in MI
- banner, default, load, and module commands in boot.cfg(5) could be common
- clear, consdev, more than one menu items (and format) commands
  in boot.cfg(5) should be optional per each port
- some MI file system specific libsa sources already have knobs to
  return necessary module names for them (via FSMOD and FSMOD2)
  and we can update other ones

Passing the default commands to a bootloader via boot.cfg(5)
file is enough to make the bootloader load specific modules
per boot media settings, and most ports can have such implementation,
I think (though it's still imaginary). No idea what will modules_enabled
help for us.

---
Izumi Tsutsui