Re: vnd.c 1.254

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

On Jan 17,  5:52pm, Manuel Bouyer wrote:
} 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).

     Actually, ipf has backwards compat these days.  There is very
little left that doesn't have backwards compat.

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

     One could argue that not sorting the list is a bug. :->  Also,
spitting out strange errors under normal usage is a bad thing.
However, these are side issues to the real.  Except that spitting
out strange errors may be related to the real problem.

}-- End of excerpt from Manuel Bouyer