[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Specifying names for tap interfaces
Christos Zoulas wrote:
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.
Main Index |
Thread Index |