Well, one good example comes to mind:

On the mac68k port, there is an option to load the kernel from a
MacOS filesystem.  The kernel loaded this way may or may not exist
in the NetBSD world, but there is _definitely_ no way to access it
from within NetBSD, since we don't have a MacOSfs!

On Sat, 9 Jan 1999, Charlie Root wrote:

> 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.
> 
> 
> 
> 

-----------------------------------------------------------------------------
| Paul Goyette      | PGP DSS Key fingerprint:   | E-mail addresses:        |
| Network Engineer  |   BCD7 5301 9513 58A6 0DBC |  paul@whooppee.com       |
| and kernel hacker |   91EB ADB1 A280 3B79 9221 |  paul.goyette@ascend.com |
-----------------------------------------------------------------------------