On Jan 18, 12:52am, Robert Elz wrote:
}
} Date: Sun, 17 Jan 2016 17:52:16 +0100
} From: Manuel Bouyer <bou...@antioche.eu.org>
} Message-ID: <20160117165216.ga4...@asim.lip6.fr>
}
} | 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.
}
} But that makes no sense at all, there are only one set of devices, just
} multiple different sets of names for them. This is why vnconfig should
} not be looking in /dev (as it never did before NetBSD 7)
}
} | yes, but that's not how one would use it.
}
} It might be. Particularly with something like xen, qemu, virtualbox
} (as a host) it might make sense to have vnd device files with known
} fixed names (root, usr, home ...) in each config directory (accessing
} different kernel vndN's of course), and then have the startup scripts
} not need configuration, or to go hunting for a suitable vnd.
Currently, there is no simple way of doing that, at least not
for Xen.
} | One would use vnconfig -l to find a usable device in /dev,
}
} No, one wouldn't, as is evidenced by the fact that that is not the
} method that the xen config script uses. It does it the right way
} (which includes looking at what is available in /dev, though if needed,
The only place the Xen script does look is in /dev. It seems
kind of strange to be arguing that it is correct for the Xen script
to look in /dev, but that isn't correct for vnconfig -l to do so.
After all, they are essentially doing the same thing in order to
find out what vnds exist.
} making a new set of vndN's there is trivial - if I used xen enough
} (that is, making new clients frequently) I think I'd have the script just
} MAKEDEV a new one if all the existing entries in /dev were in use.)
Hrmm... automagic...
} | so you need the /dev entry.
}
} You need a (set of) special files to create and access the device.
} They do not need to be in /dev.
True, but if you put them elsewhere, you're on your own to
manage them, and I don't see a problem with that.
} | I say that what's in /dev/ is now relevant because this is what limits
} | the number of vnd you can use
}
} No it doesn't. Not in any way at all.
Now, you're just splitting hairs.
} | Older vnconfig -l listing devices without checking that a /dev/ entry
} | exists may also be seens as a bug.
}
} No, it wasn't, it told which vnds were in use, and which were free,
} regardless of which path names might be available to access the free ones,
} or which had been used to config the busy ones. That's useful.
} It is still useful now, except now there are too many free vnd's to
} list, so the rational approach is to deduce which are free given
} knowledge of which are busy. The information is still there, just
} in a different form.
}
} | The only limit is what's in /dev/ so listing what's in /dev is fine.
}
} But that isn't a limit, and isn't material in any case.
}
} | > 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.
}
} I have now, and it looks like the pullup did not happen. Christos put
} a comment in the commit on head
} XXX: pullup to 7 together with the kernel change.
} but it appears as if that did not happen.
}
} It needs to. The vnconfig (vndconfig now) and kernel changes are a set,
} one without the other is definitely broken.
}
} Christos: can you request that please?
}
} | You didn't look at the code I guess.
}
} That's because you're still running the 7.0 release vnconfig (because
} that is what is still on the netbsd-7 branch). That's simply broken, and
} it is not surprising that you are seeing problems with vnconfig -l.
}
} Note that all of this occurred because NetBSD 7 got a broken hack to
} vnconfig to work around the change to being a cloning (which ignored
} backwards compat) rather than fixing it in a rational way, which has
} now been done ... just not yet(fully) pulled up to -7 and -7-0
}
} And this (irrelevant side issue) still doesn't explain what is happening
} with the xen startup, which doesn't use vn{d}config -l You wouldn't
} even be thinking about it if you had not noticed (largely because of
} the mismatch of vnconfig & kernel) the change while looking for whatever
} the real issue is here. You also didn't object when the original
} problem, and this solution, were being discussed early last November.
}
}-- End of excerpt from Robert Elz
