On Sat, 9 Jan 1999, Paul Goyette wrote:

> 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!
 
	It would be possible to keep same-named copies of each kernel
	you want to use in both MacOS and the NetBSD root filesystem.
	Its extra work, but it allows for the right thing to happen
	when you swap back and forth between kernels.  If you don't
	make the extra effort, you're no worse off.

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

	The communication is not particularly hard (it may be harder in
	some port than others, but it certainly should be feasible). At
	the worst case it can always fall back to '/netbsd' on ports where
	it is not implemented (yet :)

> > >         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.
> > 
	(As Paul mentioned), sometimes you cannot get to the filesystem
	containing the kernel.

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

	Not too bad at all as far as I can work out :)

	Another possibility would be to modify the bootloader to also load
	the necessary symbols into memory, then have a program run in rc
	that generates /var/db/kvm.db, then tells the kernel to release the
	memory.

		David/absolute

                      Neighbours should be one of:
                a) Understanding   b) Distant   c) Deaf