| Message ID | 1404980258-30853-11-git-send-email-teg@jklm.no |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | David Miller |
| Headers | show |
Tom Gundersen <teg@jklm.no> writes: > A fixed number of indistinguishable dummy devices are allocated at module init time, > the names are therefore PREDICTABLE rather than ENUM. OK? So if I go do modprobe dummy numdummies=2 ip link add type dummy ip link add type dummy then I'd have dummy0 and dummy1 with NET_NAME_PREDICTABLE, but dummy2 and dummy3 with NET_NAME_ENUM (from your rtnetlink patch). I think this just demonstrates that there aren't that many different name types. There is no real difference between your NET_NAME_ENUM and NET_NAME_PREDICTABLE, resulting in arbitrary choices like this one. The same goes for NET_NAME_USER and NET_NAME_RENAMED. These are the same from a kernel point of view. If userspace wants to keep track of device name history then it is free to do so without any need for a RENAMED type. Bjørn -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 10, 2014 at 11:31 AM, Bjørn Mork <bjorn@mork.no> wrote: > Tom Gundersen <teg@jklm.no> writes: > >> A fixed number of indistinguishable dummy devices are allocated at module init time, >> the names are therefore PREDICTABLE rather than ENUM. > > OK? So if I go do > > modprobe dummy numdummies=2 > ip link add type dummy > ip link add type dummy > > then I'd have dummy0 and dummy1 with NET_NAME_PREDICTABLE, but dummy2 and > dummy3 with NET_NAME_ENUM (from your rtnetlink patch). Correct. Granted, this is definitely a grey area (the distinction between the name assign types is less important for virtual devices), but I still think this makes sense: The result of modprobe dummy numdummies=2 is to create dummy0 and dummy1, always with the same names. The result of ip link add type dummy is to create dummyX, where X depends on what came before. > I think this just demonstrates that there aren't that many different > name types. There is no real difference between your NET_NAME_ENUM and > NET_NAME_PREDICTABLE, resulting in arbitrary choices like this one. It is true that in some cases the distinction is less important, but that does not negate the usefulness: For instance, the kernel may assign names to interfaces based on information provided by their firmware. These names may be useful to keep, and it may be important for userspace to be told that they are backed by something sensible. > The same goes for NET_NAME_USER and NET_NAME_RENAMED. These are the same > from a kernel point of view. You mean to collapse the two, and just label renamed interfaces NET_NAME_USER instead? > If userspace wants to keep track of device > name history then it is free to do so without any need for a RENAMED > type. Just for the record, I don't see how userspace can keep track of device name history (as some of the history may predate userspace being around). Getting the history is not important though, what we care about is the nature of the current name. Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi >> The same goes for NET_NAME_USER and NET_NAME_RENAMED. These are the same >> from a kernel point of view. > > You mean to collapse the two, and just label renamed interfaces > NET_NAME_USER instead? I have no real objections to merging NAME_USER and NAME_RENAMED. Both values imply that there is a user-space authority that applied some kind of rules to the naming-scheme. Therefore, anyone reacting to those names should better treat them equally and fix the naming-authority instead of overwriting it. However, at the same time I think there's no real harm in keeping them separate, either. My original thinking was to provide a second layer for anyone overwriting system defaults. For instance, if there's a user-space given name and a system-administrator wants to rename that for administrative purposes, they can safely match on NAME_USER and be sure, it wasn't renamed, yet. If it is set to NAME_RENAMED, though, then the administrator has some kind of safety-net that tells him he already has a rule that renamed the device and he shouldn't add another one (like placing one in initrd and one in the real root). Anyhow, if no-one cares about that, please go ahead and squash both into NET_NAME_USER. Thanks David -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 10, 2014 at 12:26 PM, David Herrmann <dh.herrmann@gmail.com> wrote: > Hi > >>> The same goes for NET_NAME_USER and NET_NAME_RENAMED. These are the same >>> from a kernel point of view. >> >> You mean to collapse the two, and just label renamed interfaces >> NET_NAME_USER instead? > > I have no real objections to merging NAME_USER and NAME_RENAMED. Both > values imply that there is a user-space authority that applied some > kind of rules to the naming-scheme. Therefore, anyone reacting to > those names should better treat them equally and fix the > naming-authority instead of overwriting it. I basically agree. There is no strong reason to keep these separate, so I would not object strongly to merging them. However, I also don't see any harm in keeping the distinction. If userspace wants to treat them the same, it easily can. However, if a usecase appears in the future where the distinction is important, we can no longer split them apart again. For that reason, I'd slightly prefer keeping them separate, unless there is a compelling reason not to... Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Tom Gundersen <teg@jklm.no> writes: > The result of > > modprobe dummy numdummies=2 > > is to create dummy0 and dummy1, always with the same names. > > The result of > > ip link add type dummy > > is to create dummyX, where X depends on what came before. Which is no different. That's exacly what happens when "modprobe dummy numdummies=2" creates the two first interfaces. ip link add link wwan0 name dummy0 type vlan id 2 modprobe dummy numdummies=2 ends up with dummy1 and dummy2 created by the dummy driver. You are trying to make up differences that just aren't there. Bjørn -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 10, 2014 at 1:44 PM, Bjørn Mork <bjorn@mork.no> wrote: > Tom Gundersen <teg@jklm.no> writes: > >> The result of >> >> modprobe dummy numdummies=2 >> >> is to create dummy0 and dummy1, always with the same names. >> >> The result of >> >> ip link add type dummy >> >> is to create dummyX, where X depends on what came before. > > Which is no different. That's exacly what happens when > "modprobe dummy numdummies=2" creates the two first interfaces. > > > ip link add link wwan0 name dummy0 type vlan id 2 > modprobe dummy numdummies=2 > > ends up with dummy1 and dummy2 created by the dummy driver. > > You are trying to make up differences that just aren't there. Ah, good point. You are right. So the dummy interfaces should be labelled NET_NAME_ENUM. I suppose the distinction should be that statically created devices like these should be NET_NAME_PREDICTABLE only if they fail when the name they want is already taken (rather than just picking the next one). Thanks for looking into this! Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c index ff435fb..3eef710 100644 --- a/drivers/net/dummy.c +++ b/drivers/net/dummy.c @@ -164,7 +164,7 @@ static int __init dummy_init_one(void) struct net_device *dev_dummy; int err; - dev_dummy = alloc_netdev(0, "dummy%d", NET_NAME_UNKNOWN, dummy_setup); + dev_dummy = alloc_netdev(0, "dummy%d", NET_NAME_PREDICTABLE, dummy_setup); if (!dev_dummy) return -ENOMEM;
A fixed number of indistinguishable dummy devices are allocated at module init time, the names are therefore PREDICTABLE rather than ENUM. Signed-off-by: Tom Gundersen <teg@jklm.no> Cc: dingtianhong <dingtianhong@huawei.com> Cc: Tan Xiaojun <tanxiaojun@huawei.com> Cc: WANG Cong <xiyou.wangcong@gmail.com> --- drivers/net/dummy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)