Alan Barrett wrote:
> There's already an easy way to find the booted kernel: $(sysctl
> machdep.booted_kernel).  I suppose that's not easy enough for some people,

See earlier in the thread for why that isn't, and intrinsically cannot
be, sufficient. It isn't a property of "some people," it's a property
of the problem.

At the risk of repetition:

What the kernel receives from the boot loader, if anything, is the
base name of the kernel, according to the boot loader's view of the
file system that contains the kernel and loader.

That file system is not necessarily the file system that will be
mounted as root when the kernel is initialized, and it is not
necessarily even local.  Commonly the admin will set things up so
that fs is mounted and visible /somewhere/, but /where/ is not
something the boot loader knows. Only in some cases (local file
system findable in the mount table) could the kernel even be
expected to figure it out, and it is probably not worth writing
the code to figure it out when only some cases could be covered.

The entity who knows what the correct path prefix will be is the
human administrator, who will be setting up the local mount, NFS
mount, or whatever other arrangement makes the kernel file system
visible.  That does not mean machdep.booted_kernel is unimportant;
it is important, because it indicates /which/ kernel on the kernel
file system has been booted.  But in general it cannot DTRT unless
combined with a path prefix supplied by the administrator.

> I see two obvious ways of allowing a fixed file name to DTRT: a magic
> symlink, or a magic kernfs node.  I think I'd prefer a kernfs node,
> like /kern/kernel, and it has the advantage that it would be possible
> (in principle) to make it work in some situations where a magic symlink
> would not work.

In the case of the symlink, the human administrator supplies the
necessary human-supplied part of the path by typing

  ln -s /human-part-of-path/@booted_kernel /netbsd

In the case of a kernfs node, how is it supplied? Or are you intending
the kernfs node to simply /be/ the kernel file node, which eliminates
any need for the client to know the name?  That could be handy, but
what will the underlying mechanism be when the kernel was booted over
TFTP, say, and the kernel file isn't otherwise available?

-Chap