Christos Zoulas wrote:
In article<20120704193411.GA2165%antioche.eu.org@localhost>, Manuel Bouyer<bouyer%antioche.eu.org@localhost> wrote:On Wed, Jul 04, 2012 at 06:34:36PM +0100, Roger Pau Monne wrote:if I did read it properly, there's no way to know the driver and unit number once the name has been changed ?Yes it is, drvctl -p<new_name>, will print the driver and unit number.OK, I see.Also, there is a change to bpf that looks unrelated. As it changes the semantic, this should at last be documented.The change to bpf is explained in the email. It is changed to accept interfaces not ending in a number, so you can use for example foo2bar as an interface name.Dareen pointed out that such name would cause problems with various tools. I guess bpf is not the only place that needs to be fixed.I still don't see justification for this feature. Why can't the parent open the device and pass the name/fd to the child?
Sorry, I've replied to this thread using my cell phone once, and it seems the messages didn't get to the list because they where in HTML.
I didn't intend to solve the Qemu issue using this patch, since this feature will not be present in NetBSD 6, and I aim for new Qemu present in Xen unstable (4.2) to work with NetBSD 6.
I haven't tried yet, but I assume passing the fd to Qemu will work, and I plan on using that to fix the Qemu problem. Anyway I had this half done, because I think it's an interesting feature, not only as a fix to the Qemu issue. For example being able to name Xen virtual interfaces in the Dom0 with a user defined name (both tap and vif), but I'm sure other users will come up with other uses.