Re: vnd.c 1.254

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

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

  | unless you run vnconfig in the chroot.

And /dev in the chroot has the same vnds in it that /dev has

  | listing what is available in /dev makes sense to me, as, unless you have a
  | very special setup, you'll use what's in /dev/ anyway.

Usually, yes, but "usually works" isn't really good enough.

  | You could use an option to list other devices in other directories.

You'd also need an option to give their names.   Consider

	mknod mydir/foo-pt1 c 14 0
	monod mydir/bar-pt2 c 14 1
	mknod mydir/xxx-pt3 c 14 2
	mknod mydir/vnd-raw c 14 4
	vmconfig $(pwd)/mydir/vnd-raw /some/image/file
	mknod other/foo-pt1 c 14 16
	mknod other/bar-pt2 c 14 17
	mknod other/xxx-pt3 c 14 18
	mknod other/vnd-raw c 14 19
	rm -f /dev/vnd*

What would you like vnconfig -l to list, and how would you expect to
achieve it?

  | or just list what's in /dev/

That's not backward compat with any NetBSD prior to NetBSD7.
Take your netbsd 5 that you used for the previous example, remove
all the /dev/vnd* (or move them somewhere) and try vnconfig -l
again.   I think you'll see the same output as you did before.
Similarly if you MAKEDEV vnd{5,6,7} it will still just list vnd 0..3
What is in /dev was always irrelevant.   NetBSD 7 is just broken in
this area.

  | True, that's why I insist on vnconfig -l to list free devices as it used
  | to (although I don't use it myself).

If you can work out what that really means (not looking at /dev) in a
way that makes sense, that would be fine.  I cannot (other than listing
all 4 billion.)

  | I'm talking about vnconfig -l not listing free devices, no about
  | vnconfig getting spurious ENXIO

I know, and I still doubt that it matters.

  | it is a kernel and an userland from netbsd-7, not HEAD.

I understand.

  | Anyway vnconfig didn't change in netbsd-7 since 7.0.

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.

  | And even if it did, I would expect vnconfig from 7.0_RELEASE to work
  | with a netbsd-7 kernel

Normally I would do, but ...

  | (for backward compat it's more important than a netbsd-6 vnconfig with
  | a netbsd-7 kernel)

I disagree.   The number of people upgrading 7.0 to -7 (and doing
it by only upgrading the kernel) is going to be far fewer than the
number upgrading from 6 (and earlier.)   If a 7.0.1 had already
been released it wouldn't even be an issue.

  | > All 4 billion of them?
  | No, what's in /dev/ as it used to do in 7.0-RELEASE

I bet it isn't.   MAKEDEV a few more vnds in /dev and try
again, changing nothing else.  If it appears to be listing
all that is in /dev, that is just co-incidence.

  | When the problem did show up, only vnd0 and vnd1 were in use.
  | vnconfig -l did show on vnd0 and failed with ENXIO on vnd1 (although the
  | device was configured because it was, and is still, in use by a domU).

That would be a bug, that we need to find and fix.   If vnd1 is in use,
it should be listed.

It may be the same bug that is causing the xen startup problem, or it
might be a different one.   Was it a (bare) "vnconfig -l" that failed?
If you (or anyone else) sees this again, also try "vnconfig -l vnd1"
(or whichever one vnconfig -l fails on and is known to be in use.)

kre