Re: vnd.c 1.254

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Jan 17, 11:04pm, Robert Elz wrote:
}
}     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?

     If you're going to do bonkers things, then you should expect
the system to behave in bonkers ways.  It is unreasonable to expect
the system to handle every corner case that a sysadmin on crack
can create.

}   | 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

     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.

} been released it wouldn't even be an issue.

     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.

}   | > 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.)
} 
}-- End of excerpt from Robert Elz