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 <bou...@antioche.eu.org> } > Message-ID: <20160117145238.ga3...@asim.lip6.fr> } > } > | 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 bui...@b45.netbsd.org } 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