On Sun, Jan 17, 2016 at 09:37:49PM +0700, Robert Elz wrote:
> Date: Sun, 17 Jan 2016 14:49:23 +0100
> From: Manuel Bouyer <bou...@antioche.eu.org>
> Message-ID: <20160117134923.ga2...@asim.lip6.fr>
>
>
> | I mean, vnconfig -l (without other arguments) has been showing available
> | devices for a long time:
>
> Yes, I know, and agree, it has ... but that is only possible if it
> is possible to rationally enumerate the available devices. When there
> were a fixed (small) number, it made sense. That is no longer the case.
>
> Do you really want it to list 4 billion free vnds ?
>
> Using what is in /dev is incorrect (always was) as /dev is just a
> convention (and particularly is not reliable when chroots are in use).
unless you run vnconfig in the chroot.
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.
You could use an option to list other devices in other directories.
> | this is a major behavior change, which may well break existing setups.
>
> True, but there is little alternative, unless you'd like to return to
> the pre cloning days. It can stay as it is now, listing free devices
> up to the highest used (but that really is hard to explain and makes
> little sense, and as you have observed, is not very reliable) or I guess
> we could just add a
>
> for (n = highest_found; ++n < highest_found + 4; )
> printf("vnd%d: not in use\n", n);
>
> after it finishes printing, just to list a few more free ones.
or just list what's in /dev/
>
> | You remove existing and working functionality to fix a marginal backward
> | compatibility issue ?
>
> Not marginal at all, and backwards compat has always been one of NetBSD's
> prime objectives.
True, that's why I insist on vnconfig -l to list free devices as it used
to (although I don't use it myself).
>
> | But removing this functionality is breaking
> | backward compat, in a much more important way.
>
> Actually, I doubt it. I suspect some other issue is the problem here,
> and the change to vnconfig -l is just confusing the issue.
I'm talking about vnconfig -l not listing free devices, no about
vnconfig getting spurious ENXIO
>
> | we *are* already running an up to date vnconfig, dammit !
>
> Ah, OK, I misread your description (I thought you meant one from 7.0)
it is a kernel and an userland from netbsd-7, not HEAD.
Anyway vnconfig didn't change in netbsd-7 since 7.0. And even if it did,
I would expect vnconfig from 7.0_RELEASE to work with a netbsd-7 kernel
(for backward compat it's more important than a netbsd-6 vnconfig with
a netbsd-7 kernel)
>
> | not until this problem is fixed. Breaking XEN3_DOM0 support is a real
> | problem.
>
> Agreed, we need to work out what is causing that vnconfig to fail.
>
> | Unfortunably it's transient.
>
> That does make it difficult to debug.
>
> | After a view vnconfig manipulations the
> | problem is gone for me (and vnconfig -l again show all devices,
> | used or free).
>
> All 4 billion of them?
No, what's in /dev/ as it used to do in 7.0-RELEASE
>
> | cd_ndevs is now at 8 (checked with gdb against /dev/mem)
>
> Then at some stage you had vnd7 configured.
yes, probably. I start/stop domUs on a regular basis on this dom0.
Or maybe I just did run vnconfig -l vnd7.
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).
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
