Date: Fri, 16 May 2025 11:12:38 +0200
From: Christoph Badura <b...@bsd.de>
Message-ID: <20250516091238.gp14...@irregular-apocalypse.k.bsd.de>
| Is the emphasis on an *embedded* slash to be taken literally?
Yes, that's the point.
| I.e. are leading and trailing slashes considered embedded or not?
Leading slashes no - that's the point of this proposal from Paul, which
he should just go ahead and commit, it is a truly trivial change.
| The code just checks if filename *contains* a slash.
That's what the change which is the subject of this e-mail is intended
to fix.
The point is that
boot netbsd
and
boot /netbsd
currently mean the exact same thing, or rather, used to. And some of us
use one of those and others the other. But as the code is now, without
the current proposed change, they are no longer the same, the first
will proceed to also try netbsd/kernel if netbsd isn't a bootable file,
whereas the second won't. That should be fixed. Doing so is a very minor
change (and no Taylor, it won't break anything).
I doubt trailing slashes mean anything however, I doubt anyone does
boot netbsd/
and expects that to work, though with KERNEL_DIR that could easily
be made to mean to skip the attempt to boot netbsd as a file, and
proceed directly to netbsd/kernel (there is no code yet suggested to
make that happen, but it would be truly trivial to achieve, and is
quite likely a good idea).
And to address another point raised earlier (while replying to list e-mail
was almost impossible for me for a few days), the "filename" there, is,
and has been essentially forever, a path name - just in most documentation
we don't explicitly say "path name" except when it truly makes a difference.
eg: cat(1)
SYNOPSIS
cat [-beflnstuv] [-B bsize] [-] [file ...]
but we all know (I hope) that we don't actually give files as args to
cat, we give the name of a link to the file (ie: a filename) and that
that filename isn't limited to being a filename component, it can be
any pathname. Saying "file" or "filename" in these contexts is just
a shorthand, which in general, everyone understands - if only a filename
component (something which can appear in a directory) is permitted, the
doc will (or should) be very explicit about that.
The same is true of the path searches in the standalone code that boot
uses, the only real difference is that there is no equivalent to "cd"
in the standalone code, all path lookups treat "./" and "/" identically,
the current working directory is always root.
But it is possible to
boot /path/to/any/where/I/like
provided I only like paths within the filesystem being searched (there
are no mount points either), but I can say
boot device:/whatever/file/I/want
and device can be NAME=xxx (at least in efiboot, not sure if the older
boot programs understand that, but I'd guess not) but "hd1e" should
certainly work. Of course, for some architectures there might be some
differences, which is why all of this discussion is x86 specific.
kre
ps: none of this actually matters to me, I don't use modules, so have
no interest in having the modules at all, let alone making sure that the
correct modules are associated with the appropriate kernel binary.
All my kernels (the ones I ever boot) get compiled with "no options MODULAR"
in their configs.
