I think I know less about BSD kernels than anyone else, but this
one appears easy.  I may look like a fool after I've said it, but,
hey, it's how you learn.  When flaming me, please be specific.

David Brownlee wrote:

>         We should really make machdep.booted_kernel a MI variable -
>         all ports would benefit (or at the worst not fail), from this
>         facility. At the moment if you boot '/netbsd.test' everything
>         will run against /netbsd, which is just... lame.

You appear to be talking about a communication between
the bootloader and the kernel.  Why would this be hard?
One would seem to want a clever hack.

>
>
>         For netbooted or similar environments where you cannot access
>         the original kernel you could at least check for the same filename
>         in the root filesystem. It might be wrong, but it will be right
>         much more often than the current situation...

Why can't you access the original kernel?  What prevents the invention
of a convention by which the kernel and the bootloader, whatever it
may be, from sharing a preconfigured block of memory, even across
platforms?  This does not seem like rocket science to me.  The problem
is doing it in a way that survives ports across machine architectures.

>
>
>                 David/absolute
>
>                   -=- Why _do_ we crucify ourselves?  -=-
>
> On Sat, 9 Jan 1999 drochner@zel459.zel.kfa-juelich.de wrote:
>
> >
> > soren@t.dk said:
> > > I was thinking of some more general way of accomplishing what
> > > machdep.booted_kernel does, i.e. mostly where to point kvm_mkdb at.
>

What Soren wants sounds reasonable.  The bootloader knows where it
got things from including, if a netloaded kernel, what the TCP/IP or other
network configuration data was.  Presumably, this being NET-BSD, the
kernel will be able to drive the network as well.

Is there, hence, a way for the bootloader to leave behind, in a manner that
survives all supported and future architectures, a block of memory the
kernel can read, a short letter of love and trust from the bootloader,
telling the kernel from whence it came?  This seems to be what is wanted.

Bootloaders are machine specific to the extent that few machines share
instruction sets.  This can be used to advantage.  A bootloader knows
the unconditional jump instruction for its processor.  It can place this,
by convention, at the head of the kernel leaving just enough space for
whatever information is desired that the bootloader communicates.
This can be an original filesystem, a mount point, or a set of network
configuration parameters so that the kernel can read this data and
know from whence it came (which it can use to get back there if it
so desires and the necessary driver is in that kernel).

Say that one leaves a 1k space at the head of the kernel, reserves 16
bytes for now for the jump instruction, and uses the rest as structured
data.  If the kernel is configured so as leave this space addressable,
the communication mechanism is now in place.  I suggest the head
of the kernel as it will be there despite future growth, the load
of additional drivers or varying upper memory limits.

Granted that it is a hack, and ugly, but it should be workable.  The
details of where to put it depend on the bootloader and kernel
cooperating only to the extent that the kernel can make the
statement "My first 1k is my bootloader's message to me."  It
should be able to reside in nearly any code space since it requires
only to be read.

That's it.  How badly did I do?

--
It is not enough that I should win.  Everyone else must lose.