Re: vnd.c 1.254

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

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 <bouyer%antioche.eu.org@localhost>
>     Message-ID:  <20160117134923.GA2010%asim.lip6.fr@localhost>
> 
> 
>   | 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 <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--