Date: Sun, 17 Jan 2016 12:42:32 -0800
From: John Nemeth <jnem...@cue.bc.ca>
Message-ID: <201601172042.u0hkgwot016...@server.cornerstoneservice.ca>
| If you're going to do bonkers things, then you should expect
| the system to behave in bonkers ways.
That wasn't bonkers, just unconventional. There has never been a
requirement that special files exist only in /dev, it is just a
convention. I certainly would not expect everything to work with
a config like I described (shortcuts like referring to just "vnd0"
are not going to work, and that's OK). But I do expect basic
functions to continue to work correctly.
| That isn't necessarily true. It is certainly feasible in many
| cases and possibly even desirable in some cases to run with a 7.0
| kernel on a 6.X userland for some time to make sure things are
| going to work out okay. It is much easier to change the kernel
| then it is downgrade userland, especially since there is no officially
| supported method for doing the latter.
In that it looks like you believe that you are disagreeing with me.
You're not, that's simply a better exposition of what I have been saying.
Compat with netbsd 6 userland is required. That's what last November's
changes restored.
| This, also isn't necessarily true. 7.0.1 won't see all pullups
| that netbsd-7 does (7.0.1 will come from the netbsd-7-0 branch).
| 7.0.1 will only sees security and critical bug fixes, whereas 7.1
| will have general bug fixes, updated/new device drivers, etc.
That will be someone else's call, but I would have though a vnconfig
where the -l option essentially runs forever, would be a critical enough
bug, with a simple enough fix, that the fix would get pulled up (and
in fact, the kernel part already has - it was done in version
1.232.2.3.2.1 of dev/vnd.c). It just needs the matching userland
pullup as well (which seems to have missed out on being requested
originally, though that has been fixed now.)
And from a later message
(<201601172101.u0hl11cv023...@server.cornerstoneservice.ca>) ...
| The only place the Xen script does look is in /dev. It seems kind of
| strange to be arguing that it is correct for the Xen script to look in /dev,
| but that isn't correct for vnconfig -l to do so. After all, they are
| essentially doing the same thing in order to find out what vnds exist.
Not at all. They're doing different things for different purposes. The
xen script needs to find a special file that it can configure, for that
looking in /dev (the normal place to find such files) is entirely reasonable.
[Aside: a config option to specify which vnd device, which could allow the
special file to be anywhere, would be nice, and probably already exists.]
On the other hand, vnconfig is just revealing internal kernel status to
the user. The names it prints (vnd0: ...) aren't used for anything else.
There isn't even any guarantee that /dev/vnd0[a-p] and the kernel vnd0
are related in any way at all. They usually will be, but need not.
That wouldn't bother other users, No-one should really care which internal
kernel unit is accessed by a particular vndN[a-z] set of special files.
kre
