Re: vnd.c 1.254

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

On Sun, Jan 17, 2016 at 11:04:23PM +0700, 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

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.
I can't see a problem with that.

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

As long as the limitations are known and documented I don't have a
problem with that. If we remove all softwares that only "usually works"
we can just drop computers away

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

yes, but that's not how one would use it. One would use vnconfig -l
to find a usable device in /dev, so you need the /dev entry.

> Similarly if you MAKEDEV vnd{5,6,7} it will still just list vnd 0..3

yes, and that's find because others are not usable even if they exists.
But now that this limitation is gone I don't have a problem with
listing all /dev entries.

> What is in /dev was always irrelevant.   NetBSD 7 is just broken in
> this area.

I say that what's in /dev/ is now relevant because this is what limits
the number of vnd you can use (and this limit can easily be raised if needed).
Older vnconfig -l listing devices without checking that a /dev/ entry
exists may also be seens as a bug.

> 
>   | 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.)

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

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

You can check that. But a pullup that remove a functionality that
has been there for at last 2 release should be rejected.

> 
>   | 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.)

of course not. I guess it's common to run userland from a release and
kernel from the corresponding stable branch. Running a kernel from a
different stable branch than userland is much less common (because you
expect things to break, e.g. ipf).

> If a 7.0.1 had already
> been released it wouldn't even be an issue.

That wouldn't change the problem at all.

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

You didn't look at the code I guess.
xen1:/root#uname -a
NetBSD xen1.soc.lip6.fr 7.0_STABLE NetBSD 7.0_STABLE (XEN3_DOM0) #12: Wed Jan  6 16:47:39 CET 2016  bouyer@hop:/dsk/l1/misc/bouyer/tmp/amd64/obj/dsk/l1/misc/bouyer/netbsd-7/src/sys/arch/amd64/compile/XEN3_DOM0 amd64
xen1:/root#head -15 /etc/release
NetBSD 7.0_STABLE/amd64

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

Build information:
          Build date   Tue Jan 12 06:12:17 UTC 2016
            Built by   builds%b45.netbsd.org@localhost
            Build ID   201601120520Z
[...]
xen1:/root#vnconfig -l
vnd0: /domains (/dev/wd0f) inode 3
vnd4: not in use
vnd5: not in use
vnd6: not in use
vnd7: not in use
vnd1: /domains2 (/dev/raid1e) inode 4
vnd2: not in use
vnd3: not in use
xen1:/root#cd /dev
xen1:/dev#./MAKEDEV vnd9
xen1:/dev#cd /
xen1:/#vnconfig -l
vnd0: /domains (/dev/wd0f) inode 3
vnd4: not in use
vnd5: not in use
vnd6: not in use
vnd7: not in use
vnd1: /domains2 (/dev/raid1e) inode 4
vnd2: not in use
vnd3: not in use
vnconfig: VNDIOCGET: Device not configured
xen1:/#vnconfig -l vnd9
vnd9: not in use
xen1:/#vnconfig -l
vnd0: /domains (/dev/wd0f) inode 3
vnd4: not in use
vnd5: not in use
vnd6: not in use
vnd7: not in use
vnd1: /domains2 (/dev/raid1e) inode 4
vnd2: not in use
vnd3: not in use
vnd9: not in use

as you can see what's in /dev/ matters.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--