Discussion about the port of NetBSD to the virtual machine monitor Xen ()

Darren Reed | 30 Jun 2012 05:08

Re: Specifying names for tap interfaces

On 30/06/2012 2:47 AM, Roger Pau Monné wrote:
...
>> > For example being able to name Xen virtual interfaces in the
>> > Dom0 with a user defined name, but I'm sure other users will come up with
>> > other uses. What would you require for this functionality?
>>
>> At the very last, being able to get the driver name and instance
>> number in a convenient way (e.g. in ifconfig output).
> 
> Ok, I will take a look at that, which I guess will require the
> introduction of a new ioctl and a corresponding field in ifnet.
> You could always find the original name in dmesg, since everytime
> the name changes a line is printed, but I agree it might be
> confusing and difficult if you perform a lot of renames.

Start with making the information available through drvctl
as part of the property list for the driver and don't worry
about ifconfig.

Darren

headers

Roger Pau Monne | 4 Jul 2012 19:05

Re: Specifying names for tap interfaces

Darren Reed wrote:
> On 30/06/2012 2:47 AM, Roger Pau Monné wrote:
> ...
>>>> For example being able to name Xen virtual interfaces in the
>>>> Dom0 with a user defined name, but I'm sure other users will come up with
>>>> other uses. What would you require for this functionality?
>>> At the very last, being able to get the driver name and instance
>>> number in a convenient way (e.g. in ifconfig output).
>> Ok, I will take a look at that, which I guess will require the
>> introduction of a new ioctl and a corresponding field in ifnet.
>> You could always find the original name in dmesg, since everytime
>> the name changes a line is printed, but I agree it might be
>> confusing and difficult if you perform a lot of renames.
>
> Start with making the information available through drvctl
> as part of the property list for the driver and don't worry
> about ifconfig.
>
> Darren

The attached patch adds a new ioctl to perform the rename and propagate 
that rename to the associated device_t and sysctl entries. Please review 
this patch and check that the use of the spls is correct. I also had to 
change a part of the code of bpf_setif in bpf.c to allow the use of 
interfaces that doesn't end with a number.

From 3e90ed906c3b93a92be302e76455a22940e56d6f Mon Sep 17 00:00:00 2001
From: Roger Pau Monne <roger.pau <at> citrix.com>
Date: Mon, 25 Jun 2012 14:58:32 +0100

(Continue reading)

headers

Manuel Bouyer | 4 Jul 2012 19:25

Re: Specifying names for tap interfaces

On Wed, Jul 04, 2012 at 06:05:02PM +0100, Roger Pau Monne wrote:
> Darren Reed wrote:
> >On 30/06/2012 2:47 AM, Roger Pau Monné wrote:
> >...
> >>>>For example being able to name Xen virtual interfaces in the
> >>>>Dom0 with a user defined name, but I'm sure other users will come up with
> >>>>other uses. What would you require for this functionality?
> >>>At the very last, being able to get the driver name and instance
> >>>number in a convenient way (e.g. in ifconfig output).
> >>Ok, I will take a look at that, which I guess will require the
> >>introduction of a new ioctl and a corresponding field in ifnet.
> >>You could always find the original name in dmesg, since everytime
> >>the name changes a line is printed, but I agree it might be
> >>confusing and difficult if you perform a lot of renames.
> >
> >Start with making the information available through drvctl
> >as part of the property list for the driver and don't worry
> >about ifconfig.
> >
> >Darren
> 
> The attached patch adds a new ioctl to perform the rename and
> propagate that rename to the associated device_t and sysctl entries.
> Please review this patch and check that the use of the spls is
> correct. I also had to change a part of the code of bpf_setif in
> bpf.c to allow the use of interfaces that doesn't end with a number.

> From 3e90ed906c3b93a92be302e76455a22940e56d6f Mon Sep 17 00:00:00 2001
> From: Roger Pau Monne <roger.pau <at> citrix.com>
> Date: Mon, 25 Jun 2012 14:58:32 +0100

(Continue reading)

headers

Roger Pau Monne | 4 Jul 2012 19:34

Re: Specifying names for tap interfaces

Manuel Bouyer wrote:
> On Wed, Jul 04, 2012 at 06:05:02PM +0100, Roger Pau Monne wrote:
>> Darren Reed wrote:
>>> On 30/06/2012 2:47 AM, Roger Pau Monné wrote:
>>> ...
>>>>>> For example being able to name Xen virtual interfaces in the
>>>>>> Dom0 with a user defined name, but I'm sure other users will come up with
>>>>>> other uses. What would you require for this functionality?
>>>>> At the very last, being able to get the driver name and instance
>>>>> number in a convenient way (e.g. in ifconfig output).
>>>> Ok, I will take a look at that, which I guess will require the
>>>> introduction of a new ioctl and a corresponding field in ifnet.
>>>> You could always find the original name in dmesg, since everytime
>>>> the name changes a line is printed, but I agree it might be
>>>> confusing and difficult if you perform a lot of renames.
>>> Start with making the information available through drvctl
>>> as part of the property list for the driver and don't worry
>>> about ifconfig.
>>>
>>> Darren
>> The attached patch adds a new ioctl to perform the rename and
>> propagate that rename to the associated device_t and sysctl entries.
>> Please review this patch and check that the use of the spls is
>> correct. I also had to change a part of the code of bpf_setif in
>> bpf.c to allow the use of interfaces that doesn't end with a number.
>
>>  From 3e90ed906c3b93a92be302e76455a22940e56d6f Mon Sep 17 00:00:00 2001
>> From: Roger Pau Monne<roger.pau <at> citrix.com>
>> Date: Mon, 25 Jun 2012 14:58:32 +0100
>> Subject: [PATCH] net: add support to rename interfaces

(Continue reading)

headers

Manuel Bouyer | 4 Jul 2012 21:34

Re: Specifying names for tap interfaces

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.

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

headers

Christos Zoulas | 5 Jul 2012 00:03

Re: Specifying names for tap interfaces

In article <20120704193411.GA2165 <at> antioche.eu.org>,
Manuel Bouyer  <bouyer <at> antioche.eu.org> 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?

christos

headers

Roger Pau Monne | 5 Jul 2012 10:37

Re: Specifying names for tap interfaces

Christos Zoulas wrote:
> In article<20120704193411.GA2165 <at> antioche.eu.org>,
> Manuel Bouyer<bouyer <at> antioche.eu.org>  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

(Continue reading)

headers

Christos Zoulas | 5 Jul 2012 16:01

Re: Specifying names for tap interfaces

On Jul 5,  9:37am, roger.pau <at> citrix.com (Roger Pau Monne) wrote:
-- Subject: Re: Specifying names for tap interfaces

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

Ah, no problem.

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

Yes, but it is a solution looking for a problem. Until we actually have
a use that makes this feature necessary, we should not add it just to avoid
creeping featurism and complexity.

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

Yes, that's nice, but purely cosmetic.

christos

(Continue reading)

headers

Roger Pau Monne | 5 Jul 2012 16:05

Re: Specifying names for tap interfaces

Christos Zoulas wrote:
> On Jul 5,  9:37am, roger.pau <at> citrix.com (Roger Pau Monne) wrote:
> -- Subject: Re: Specifying names for tap interfaces
>
> | 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.
>
> Ah, no problem.
>
> | 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.
>
> Yes, but it is a solution looking for a problem. Until we actually have
> a use that makes this feature necessary, we should not add it just to avoid
> creeping featurism and complexity.
>
> | 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.
>
> Yes, that's nice, but purely cosmetic.

It allows users to have persistent interfaces, even after Dom0/DomU 
reboot, so you can for example graph the traffic a single guest is

(Continue reading)

headers

Manuel Bouyer | 5 Jul 2012 16:41

Re: Specifying names for tap interfaces

On Thu, Jul 05, 2012 at 03:05:56PM +0100, Roger Pau Monne wrote:
> [...]
> It allows users to have persistent interfaces, even after Dom0/DomU
> reboot, so you can for example graph the traffic a single guest is
> using, which is not possible now.

It is possible, but with some script complexity ...

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

headers

Christos Zoulas | 5 Jul 2012 16:47

Re: Specifying names for tap interfaces

On Jul 5,  3:05pm, roger.pau <at> citrix.com (Roger Pau Monne) wrote:
-- Subject: Re: Specifying names for tap interfaces

| > Yes, that's nice, but purely cosmetic.
| 
| It allows users to have persistent interfaces, even after Dom0/DomU 
| reboot, so you can for example graph the traffic a single guest is 
| using, which is not possible now.

You could do the same if you assign a numeric range for them that is
high enough that will not be re-used. I would also like to mention,
that the patch is not as simple as presented. Although I have not read
it carefully, it does not seem to prevent name re-use, so one could
potentially rename an interface to an existing name, lo0 for example
and cause all kinds of lossage.

christos

headers

Roger Pau Monne | 5 Jul 2012 17:02

Re: Specifying names for tap interfaces

Christos Zoulas wrote:
> On Jul 5,  3:05pm, roger.pau <at> citrix.com (Roger Pau Monne) wrote:
> -- Subject: Re: Specifying names for tap interfaces
>
> |>  Yes, that's nice, but purely cosmetic.
> |
> | It allows users to have persistent interfaces, even after Dom0/DomU
> | reboot, so you can for example graph the traffic a single guest is
> | using, which is not possible now.
>
> You could do the same if you assign a numeric range for them that is
> high enough that will not be re-used. I would also like to mention,
> that the patch is not as simple as presented. Although I have not read
> it carefully, it does not seem to prevent name re-use, so one could
> potentially rename an interface to an existing name, lo0 for example
> and cause all kinds of lossage.

It is not possible to change the name of an interface to an existing 
one, because of this check, this prevents collusion:

if (ifunit(new_name) != NULL)
	return EEXIST;

But a user could do:

ifconfig bnx0 name tmp
ifconfig bnx1 name bnx0
ifconfig tmp name bnx1

Effectively swapping the name of both interfaces.

(Continue reading)

headers

David Laight | 5 Jul 2012 19:32

Re: Specifying names for tap interfaces

On Thu, Jul 05, 2012 at 04:02:02PM +0100, Roger Pau Monne wrote:
> 
> But a user could do:
> 
> ifconfig bnx0 name tmp
> ifconfig bnx1 name bnx0
> ifconfig tmp name bnx1

I believe linux disallows this (it causes serious grief).
(Actually it may not actually check!)

I also remember a certain system allowing interface names that ended
with digits - then add the unit number.

	David

--

-- 
David Laight: david <at> l8s.co.uk

headers

Christos Zoulas | 5 Jul 2012 16:52

Re: Specifying names for tap interfaces

On Jul 5,  3:05pm, roger.pau <at> citrix.com (Roger Pau Monne) wrote:
-- Subject: Re: Specifying names for tap interfaces

| It allows users to have persistent interfaces, even after Dom0/DomU 
| reboot, so you can for example graph the traffic a single guest is 
| using, which is not possible now.

I've been thinking about this a bit more, and I would not be averse
in letting people create named interfaces for the cloning devices as
long as the names are restricted to some form and are recognizable.
For example tun3:myvm tun4:vmx tun5:work. Some uniqueness criteria
need to be there, but the symbolic name could be just an auxiliary
tag.

christos

headers

Darren Reed | 5 Jul 2012 22:34

Re: Specifying names for tap interfaces

On 6/07/2012 12:05 AM, Roger Pau Monne wrote:
> Christos Zoulas wrote:
>> On Jul 5,  9:37am, roger.pau <at> citrix.com (Roger Pau Monne) wrote:
>> -- Subject: Re: Specifying names for tap interfaces
>>
>> ...
>> | 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.
>>
>> Yes, but it is a solution looking for a problem. Until we actually have
>> a use that makes this feature necessary, we should not add it just to avoid
>> creeping featurism and complexity.
>>
>> | 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.
>>
>> Yes, that's nice, but purely cosmetic.
>
> It allows users to have persistent interfaces, even after Dom0/DomU reboot, so you can for example graph
the traffic a single guest is using, which is not possible now.

Being able to specify the name of a network interface is
useful but I don't think the qemu case is the killer example.

The Virtual Network Stacks project that's listed the NetBSD
wiki would benefit greatly from this because it will allow
each network stack to have its own "lo0" (for example) whilst

(Continue reading)

headers

Roger Pau Monne | 6 Jul 2012 14:44

Re: Specifying names for tap interfaces

Darren Reed wrote:
> On 6/07/2012 12:05 AM, Roger Pau Monne wrote:
>> Christos Zoulas wrote:
>>> On Jul 5,  9:37am, roger.pau <at> citrix.com (Roger Pau Monne) wrote:
>>> -- Subject: Re: Specifying names for tap interfaces
>>>
>>> ...
>>> | 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.
>>>
>>> Yes, but it is a solution looking for a problem. Until we actually have
>>> a use that makes this feature necessary, we should not add it just to avoid
>>> creeping featurism and complexity.
>>>
>>> | 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.
>>>
>>> Yes, that's nice, but purely cosmetic.
>> It allows users to have persistent interfaces, even after Dom0/DomU reboot, so you can for example graph
the traffic a single guest is using, which is not possible now.
>
> Being able to specify the name of a network interface is
> useful but I don't think the qemu case is the killer example.
>
> The Virtual Network Stacks project that's listed the NetBSD
> wiki would benefit greatly from this because it will allow
> each network stack to have its own "lo0" (for example) whilst

(Continue reading)

headers

Darren Reed | 6 Jul 2012 22:40

Re: Specifying names for tap interfaces

On 6/07/2012 10:44 PM, Roger Pau Monne wrote:
> Darren Reed wrote:
>> On 6/07/2012 12:05 AM, Roger Pau Monne wrote:
>>> Christos Zoulas wrote:
>>>> On Jul 5,  9:37am, roger.pau <at> citrix.com (Roger Pau Monne) wrote:
>>>> -- Subject: Re: Specifying names for tap interfaces
>>>>
>>>> ...
>>>> | 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.
>>>>
>>>> Yes, but it is a solution looking for a problem. Until we actually have
>>>> a use that makes this feature necessary, we should not add it just to avoid
>>>> creeping featurism and complexity.
>>>>
>>>> | 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.
>>>>
>>>> Yes, that's nice, but purely cosmetic.
>>> It allows users to have persistent interfaces, even after Dom0/DomU reboot, so you can for example
graph the traffic a single guest is using, which is not possible now.
>>
>> Being able to specify the name of a network interface is
>> useful but I don't think the qemu case is the killer example.
>>
>> The Virtual Network Stacks project that's listed the NetBSD
>> wiki would benefit greatly from this because it will allow

(Continue reading)

headers

Roger Pau Monne | 13 Jul 2012 10:51

Re: Specifying names for tap interfaces

Darren Reed wrote:
> On 6/07/2012 10:44 PM, Roger Pau Monne wrote:
>> Darren Reed wrote:
>>> On 6/07/2012 12:05 AM, Roger Pau Monne wrote:
>>>> Christos Zoulas wrote:
>>>>> On Jul 5,  9:37am, roger.pau <at> citrix.com (Roger Pau Monne) wrote:
>>>>> -- Subject: Re: Specifying names for tap interfaces
>>>>>
>>>>> ...
>>>>> | 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.
>>>>>
>>>>> Yes, but it is a solution looking for a problem. Until we actually have
>>>>> a use that makes this feature necessary, we should not add it just to avoid
>>>>> creeping featurism and complexity.
>>>>>
>>>>> | 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.
>>>>>
>>>>> Yes, that's nice, but purely cosmetic.
>>>> It allows users to have persistent interfaces, even after Dom0/DomU reboot, so you can for example
graph the traffic a single guest is using, which is not possible now.
>>> Being able to specify the name of a network interface is
>>> useful but I don't think the qemu case is the killer example.
>>>
>>> The Virtual Network Stacks project that's listed the NetBSD
>>> wiki would benefit greatly from this because it will allow

(Continue reading)

headers

Darren Reed | 14 Jul 2012 12:40

Re: Specifying names for tap interfaces

On 13/07/2012 6:51 PM, Roger Pau Monne wrote:
> Darren Reed wrote:
>> On 6/07/2012 10:44 PM, Roger Pau Monne wrote:
>>> Darren Reed wrote:
>>>> On 6/07/2012 12:05 AM, Roger Pau Monne wrote:
>>>>> Christos Zoulas wrote:
>>>>>> On Jul 5,  9:37am, roger.pau <at> citrix.com (Roger Pau Monne) wrote:
>>>>>> -- Subject: Re: Specifying names for tap interfaces
>>>>>>
>>>>>> ...
>>>>>> | 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.
>>>>>>
>>>>>> Yes, but it is a solution looking for a problem. Until we actually have
>>>>>> a use that makes this feature necessary, we should not add it just to avoid
>>>>>> creeping featurism and complexity.
>>>>>>
>>>>>> | 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.
>>>>>>
>>>>>> Yes, that's nice, but purely cosmetic.
>>>>> It allows users to have persistent interfaces, even after Dom0/DomU reboot, so you can for example
graph the traffic a single guest is using, which is not possible now.
>>>> Being able to specify the name of a network interface is
>>>> useful but I don't think the qemu case is the killer example.
>>>>
>>>> The Virtual Network Stacks project that's listed the NetBSD

(Continue reading)

headers

Darren Reed | 5 Jul 2012 01:31

Re: Specifying names for tap interfaces

On 5/07/2012 5:34 AM, Manuel Bouyer 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.

It is far better to accept "<name><number>" as a naming
constraint than to try and "fix" all of the code that in
one way or another expects it to be like that.

Darren

headers

Mouse | 5 Jul 2012 03:52

Re: Specifying names for tap interfaces

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

> It is far better to accept "<name><number>" as a naming constraint
> than to try and "fix" all of the code that in one way or another
> expects it to be like that.

Why?  I don't see any reason why the name should be constrained to end
with a digit string, especially if they're going to be admin-settable.
Indeed, I would argue that code which depends on such a naming scheme
is already broken and just doesn't happen to have its brokenness
exposed by most current systems - I don't think interface names have
ever been promised to end with digits; I see them as arbitrary C
strings, with the current <name><number> format an accident of the
current implementation, not part of the interface spec.  (Of course, it
doesn't help that, as far as I know, that interface spec is entirely
unwritten....)

					Mouse

headers

Darren Reed | 5 Jul 2012 10:18

Re: Specifying names for tap interfaces

Mouse wrote:
>>> 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.
>
>> It is far better to accept "<name><number>" as a naming constraint
>> than to try and "fix" all of the code that in one way or another
>> expects it to be like that.
>
> Why?  

Because like it or not, that is the accepted defacto naming
standard for network interfaces on Un*x systems.

Darren

headers

Gert Doering | 5 Jul 2012 09:39

Re: Specifying names for tap interfaces

Hi,

On Thu, Jul 05, 2012 at 06:18:18PM +1000, Darren Reed wrote:
> Because like it or not, that is the accepted defacto naming
> standard for network interfaces on Un*x systems.

Tell that to the "lo" interface on Linux 

(But yeah, Linux is not Unix, so I need to find a different example...)

gert
--

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert <at> greenie.muc.de
fax: +49-89-35655025                        gert <at> net.informatik.tu-muenchen.de

headers

Mouse | 5 Jul 2012 09:57

Re: Specifying names for tap interfaces

> (But yeah, Linux is not Unix, so I need to find a different
> example...)

Linux is about as Unix as NetBSD is, and in much the same senses.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

headers

Roger Pau Monne | 5 Jul 2012 11:59

Re: Specifying names for tap interfaces

Darren Reed wrote:
> On 5/07/2012 5:34 AM, Manuel Bouyer 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.
>
> It is far better to accept "<name><number>" as a naming
> constraint than to try and "fix" all of the code that in
> one way or another expects it to be like that.

So far I haven't found any problem with removing this constrain in bpf, 
ifconfig, route, netstat, dhcp and ipf seem to be ok with that. Do you 
know of code which might expect interfaces to follow the <name><number> 
convention?

Thanks, Roger.

headers

Darren Reed | 5 Jul 2012 17:15

Re: Specifying names for tap interfaces

On 5/07/2012 7:59 PM, Roger Pau Monne wrote:
> Darren Reed wrote:
>> On 5/07/2012 5:34 AM, Manuel Bouyer 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.
>>
>> It is far better to accept "<name><number>" as a naming
>> constraint than to try and "fix" all of the code that in
>> one way or another expects it to be like that.
> 
> So far I haven't found any problem with removing this
> constrain in bpf, ifconfig, route, netstat, dhcp and
> ipf seem to be ok with that. Do you know of code which
> might expect interfaces to follow the <name><number> convention?

I haven't looked at every networking application that has been
written for Un*x to know and nor is it possible to do so.

Do you want to check every perl script, etc, that's ever been

(Continue reading)

headers

Darren Reed | 5 Jul 2012 10:22

Re: Specifying names for tap interfaces

Roger Pau Monne wrote:
> The attached patch adds a new ioctl to perform the rename and 
> propagate that rename to the associated device_t and sysctl entries. 
> Please review this patch and check that the use of the spls is 
> correct. I also had to change a part of the code of bpf_setif in bpf.c 
> to allow the use of interfaces that doesn't end with a number.

This patch does not appear to be safe for SMP systems where
you might have competing programs trying to rename different
interfaces to the same new name.

To reinforce the point about "<name><number>", you're changing
the device's name. How many device names in NetBSD do not
end with a number?

Darren

headers

Mouse | 5 Jul 2012 09:54

Re: Specifying names for tap interfaces

> To reinforce the point about "<name><number>", you're changing the
> device's name.  How many device names in NetBSD do not end with a
> number?

One thousand and fifteen, according to "ls /dev | egrep -v '[0-9]$' | wc'
on a handy NetBSD box.  One thousand nine hundred and twenty-three,
according to the same command on a different handy NetBSD box.

Removing the dollar sign (and thus eliminating disk partition devices,
possibly among others), I get sixty-seven and one hundred sixteen,
respectively.  Limiting it to just device special files (ls -l output
filtered with "egrep '^[bc]'"), sixty-one and one hundred and one.

Some of those functionally have numbers, just not spelled with digits
(eg [tp]ty?[a-f]).  Manually stripping those still leaves twenty-nine
and fifty-three, respectively.  Way more than zero.

(What are the 29 and 53?  To pick a random ten, thanks to shuffle -f -,
the first machine gives me tty, console, pdiskmctl (one of my own),
null, ipstate, ipauth, openprom, random, apmctl, and audioctl; the
other machine gives me ptmx, null, apm, isdnctl, constty, pf, bthub,
bio, drum, and dmoverio.)

Of course, these are userland names, and restricted to /dev entries at
that.  But this is interfaces to userland we're talking about.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

(Continue reading)

headers

Darren Reed | 5 Jul 2012 17:07

Re: Specifying names for tap interfaces

On 5/07/2012 5:54 PM, Mouse wrote:
>> To reinforce the point about "<name><number>", you're changing the
>> device's name.  How many device names in NetBSD do not end with a
>> number?
>
> One thousand and fifteen, according to "ls /dev | egrep -v '[0-9]$' | wc'
> on a handy NetBSD box.  One thousand nine hundred and twenty-three,
> according to the same command on a different handy NetBSD box.

The entries in /dev are not devices. They are named files that
allow a process to interact with the kernel in a specific fashion.

For example, /dev/ipnat is not a device that is attached to the
system, it is just a name that allows for specific IO requests
to be directed to different code than handles /dev/ipf ones.
The same is true again for disk devices, /dev/wd0a does not
refer to a physical device: you will not find a wd0a attached
to pci0 or ide0 or anything else like that. Most network devices
aren't even present in that directory.

Proper devices, such as network cards and disk drives are all
named "<name><number>".

Darren

headers

Roger Pau Monne | 5 Jul 2012 12:25

Re: Specifying names for tap interfaces

Darren Reed wrote:
> Roger Pau Monne wrote:
>> The attached patch adds a new ioctl to perform the rename and
>> propagate that rename to the associated device_t and sysctl entries.
>> Please review this patch and check that the use of the spls is
>> correct. I also had to change a part of the code of bpf_setif in bpf.c
>> to allow the use of interfaces that doesn't end with a number.
>
> This patch does not appear to be safe for SMP systems where
> you might have competing programs trying to rename different
> interfaces to the same new name.

Yes, I was expecting this. I've changed it to acquire the KERNEL_LOCK 
from the check (ifunit) to the end of change (including driver_t and 
sysctl changes). Do you think the use of splnet and driver_t mutex is 
correct?

Thanks.

headers

Darren Reed | 5 Jul 2012 17:11

Re: Specifying names for tap interfaces

On 5/07/2012 8:25 PM, Roger Pau Monne wrote:
> Darren Reed wrote:
>> Roger Pau Monne wrote:
>>> The attached patch adds a new ioctl to perform the rename and
>>> propagate that rename to the associated device_t and sysctl entries.
>>> Please review this patch and check that the use of the spls is
>>> correct. I also had to change a part of the code of bpf_setif in bpf.c
>>> to allow the use of interfaces that doesn't end with a number.
>>
>> This patch does not appear to be safe for SMP systems where
>> you might have competing programs trying to rename different
>> interfaces to the same new name.
> 
> Yes, I was expecting this. I've changed it to acquire the
> KERNEL_LOCK from the check (ifunit) to the end of change
> (including driver_t and sysctl changes). Do you think the
> use of splnet and driver_t mutex is correct?

Well answer this question - if I attempt to rename a network
device to the same name as the usb NIC that I'm about to plug
in, what race conditions are still exposed considering that
the autoconf name allocation will not use an ioctl to assign
the name?

Darren

headers

David Young | 5 Jul 2012 18:16

Re: Specifying names for tap interfaces

On Wed, Jul 04, 2012 at 06:05:02PM +0100, Roger Pau Monne wrote:
> Darren Reed wrote:
> >On 30/06/2012 2:47 AM, Roger Pau Monné wrote:
> >...
> >>>>For example being able to name Xen virtual interfaces in the
> >>>>Dom0 with a user defined name, but I'm sure other users will come up with
> >>>>other uses. What would you require for this functionality?
> >>>At the very last, being able to get the driver name and instance
> >>>number in a convenient way (e.g. in ifconfig output).
> >>Ok, I will take a look at that, which I guess will require the
> >>introduction of a new ioctl and a corresponding field in ifnet.
> >>You could always find the original name in dmesg, since everytime
> >>the name changes a line is printed, but I agree it might be
> >>confusing and difficult if you perform a lot of renames.
> >
> >Start with making the information available through drvctl
> >as part of the property list for the driver and don't worry
> >about ifconfig.
> >
> >Darren
> 
> The attached patch adds a new ioctl to perform the rename and
> propagate that rename to the associated device_t and sysctl entries.
> Please review this patch and check that the use of the spls is
> correct. I also had to change a part of the code of bpf_setif in
> bpf.c to allow the use of interfaces that doesn't end with a number.

I'm concerned that already you have had to patch a lot of code in order
to make this change, and it seems to me that the end may not be in
sight.

(Continue reading)

headers

Matthew Mondor | 6 Jul 2012 00:54

Re: Specifying names for tap interfaces

On Thu, 5 Jul 2012 11:16:10 -0500
David Young <dyoung <at> pobox.com> wrote:

> Name changes need to be observable by user programs.  The userland needs
> to be able to identify the interface whose name used to be wm0 with its
> new name, lan0.

I've not checked the renaming code closely enough, but does an
interface rename cause it to appear to detach, then reattach?  This
might solve some of the issues.

I myself have the impression that it'd be less risky, and much simpler,
to have a means to supply a custom suffix at device open (or create
ioctl, more realistically) time, which would be appended, i.e.
tap-<suffix>[-0] the number there could always be 0 as needed for code
expecting a number...  Or to use userspace solutions.

I have no objections to more complex solutions if they're free of new
problems (and am no expert on device/interface matters), but their
complexity appears to increase drastically, especially if a potential
pullup to netbsd-6 is envisaged...
--

-- 
Matt

headers

Roger Pau Monne | 6 Jul 2012 14:38

Re: Specifying names for tap interfaces

Matthew Mondor wrote:
> On Thu, 5 Jul 2012 11:16:10 -0500
> David Young<dyoung <at> pobox.com>  wrote:
>
>> Name changes need to be observable by user programs.  The userland needs
>> to be able to identify the interface whose name used to be wm0 with its
>> new name, lan0.
>
> I've not checked the renaming code closely enough, but does an
> interface rename cause it to appear to detach, then reattach?  This
> might solve some of the issues.
>
> I myself have the impression that it'd be less risky, and much simpler,
> to have a means to supply a custom suffix at device open (or create
> ioctl, more realistically) time, which would be appended, i.e.
> tap-<suffix>[-0] the number there could always be 0 as needed for code
> expecting a number...  Or to use userspace solutions.
>
> I have no objections to more complex solutions if they're free of new
> problems (and am no expert on device/interface matters), but their
> complexity appears to increase drastically, especially if a potential
> pullup to netbsd-6 is envisaged...

I don't think we should backport what ends coming up of this. The 
solution is far too complex to rush it on the netbsd-6 branch.

headers

Roger Pau Monne | 6 Jul 2012 14:57

Re: Specifying names for tap interfaces

David Young wrote:
> On Wed, Jul 04, 2012 at 06:05:02PM +0100, Roger Pau Monne wrote:
>> Darren Reed wrote:
>>> On 30/06/2012 2:47 AM, Roger Pau Monné wrote:
>>> ...
>>>>>> For example being able to name Xen virtual interfaces in the
>>>>>> Dom0 with a user defined name, but I'm sure other users will come up with
>>>>>> other uses. What would you require for this functionality?
>>>>> At the very last, being able to get the driver name and instance
>>>>> number in a convenient way (e.g. in ifconfig output).
>>>> Ok, I will take a look at that, which I guess will require the
>>>> introduction of a new ioctl and a corresponding field in ifnet.
>>>> You could always find the original name in dmesg, since everytime
>>>> the name changes a line is printed, but I agree it might be
>>>> confusing and difficult if you perform a lot of renames.
>>> Start with making the information available through drvctl
>>> as part of the property list for the driver and don't worry
>>> about ifconfig.
>>>
>>> Darren
>> The attached patch adds a new ioctl to perform the rename and
>> propagate that rename to the associated device_t and sysctl entries.
>> Please review this patch and check that the use of the spls is
>> correct. I also had to change a part of the code of bpf_setif in
>> bpf.c to allow the use of interfaces that doesn't end with a number.
>
> I'm concerned that already you have had to patch a lot of code in order
> to make this change, and it seems to me that the end may not be in
> sight.
>

(Continue reading)