Re: vnd.c 1.254

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 17 Jan 2016 12:42:32 -0800
    From:        John Nemeth <jnemeth%cue.bc.ca@localhost>
    Message-ID:  <201601172042.u0HKgWoT016961%server.CornerstoneService.ca@localhost>


  | 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.u0HL11cv023268%server.CornerstoneService.ca@localhost>) ...

  |      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