Re: vnd.c 1.254

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

    Date:        Sun, 17 Jan 2016 17:52:16 +0100
    From:        Manuel Bouyer <bouyer%antioche.eu.org@localhost>
    Message-ID:  <20160117165216.GA4949%asim.lip6.fr@localhost>

  | I don't understand that. If you run in /, you get the busy/free devices
  | in /dev, if you run in /chroot you get the busy/free devices in /chroot/dev.

But that makes no sense at all, there are only one set of devices, just
multiple different sets of names for them.   This is why vnconfig should
not be looking in /dev (as it never did before NetBSD 7)

  | yes, but that's not how one would use it.

It might be.  Particularly with something like xen, qemu, virtualbox
(as a host) it might make sense to have vnd device files with known
fixed names (root, usr, home ...) in each config directory (accessing
different kernel vndN's of course), and then have the startup scripts
not need configuration, or to go hunting for a suitable vnd.

  | One would use vnconfig -l to find a usable device in /dev,

No, one wouldn't, as is evidenced by the fact that that is not the
method that the xen config script uses.  It does it the right way
(which includes looking at what is available in /dev, though if needed,
making a new set of vndN's there is trivial - if I used xen enough
(that is, making new clients frequently) I think I'd have the script just
MAKEDEV a new one if all the existing entries in /dev were in use.)

  | so you need the /dev entry.

You need a (set of) special files to create and access the device.
They do not need to be in /dev.

  | I say that what's in /dev/ is now relevant because this is what limits
  | the number of vnd you can use

No it doesn't.   Not in any way at all.

  | Older vnconfig -l listing devices without checking that a /dev/ entry
  | exists may also be seens as a bug.

No, it wasn't, it told which vnds were in use, and which were free,
regardless of which path names might be available to access the free ones,
or which had been used to config the busy ones.   That's useful.
It is still useful now, except now there are too many free vnd's to
list, so the rational approach is to deduce which are free given
knowledge of which are busy.   The information is still there, just
in a different form.

  | The only limit is what's in /dev/ so listing what's in /dev is fine.

But that isn't a limit, and isn't material in any case.

  | > It did, or should have.   The code that looked in /dev was ripped out.
  | > If a pullup of that didn't happen, it should have.
  | 
  | You can check that. But a pullup that remove a functionality that
  | has been there for at last 2 release should be rejected.

I have now, and it looks like the pullup did not happen.   Christos put
a comment in the commit on head
	XXX: pullup to 7 together with the kernel change.
but it appears as if that did not happen.

It needs to.   The vnconfig (vndconfig now) and kernel changes are a set,
one without the other is definitely broken.

Christos: can you request that please?

  | You didn't look at the code I guess.

That's because you're still running the 7.0 release vnconfig (because
that is what is still on the netbsd-7 branch).  That's simply broken, and
it is not surprising that you are seeing problems with vnconfig -l.

Note that all of this occurred because NetBSD 7 got a broken hack to
vnconfig to work around the change to being a cloning (which ignored
backwards compat) rather than fixing it in a rational way, which has
now been done ... just not yet(fully) pulled up to -7 and -7-0

And this (irrelevant side issue) still doesn't explain what is happening
with the xen startup, which doesn't use vn{d}config -l   You wouldn't
even be thinking about it if you had not noticed (largely because of
the mismatch of vnconfig & kernel) the change while looking for whatever
the real issue is here.    You also didn't object when the original
problem, and this solution, were being discussed early last November.

kre