Chapman Flack wrote:
> 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

Do we really need this bogus symlink?

Can the admin just symlink /netbsd if /netbsd is not the real name of
the kernel.  Creating another hack like a magic symlink seems silly to me.

I think this whole thing is a non-solution to a non-problem.

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191